Tracking Issue for unix_sigpipe

[Enselic]

NOTE

The ui changed from an attribute to a compiler flag: #124480. I will update this description later.

---

The feature gate for the issue is #![feature(unix_sigpipe)].
It enables a new fn main() attribute #[unix_sigpipe = "..."].

Usage

Any simple Rust program that writes a sizeable amount of data to stdout will panic if its output is limited via pipes.

fn main() {
    loop {
        println!("hello world");
    }
}

% ./main | head -n 1
hello world
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrac

To prevent panicking we can use the new attribute:

#![feature(unix_sigpipe)]

#[unix_sigpipe = "sig_dfl"]
fn main() {
    loop {
        println!("hello world");
    }
}

% ./main | head -n 1
hello world

More Info

Please refer to the unstable book section for more details. In short:

#[unix_sigpipe = "..."]	Behaviour
sig_ign	Set SIGPIPE handler to SIG_IGN before invoking fn main(). Default behaviour since 2014.
sig_dfl	Set SIGPIPE handler to SIG_DFL before invoking fn main().
inherit	Leave SIGPIPE handler untounched before entering fn main().

The problem with the current SIGPIPE code in libstd as well as several other aspects of this problem is discussed extensively at these places:

• Should Rust still ignore SIGPIPE by default? #62569
• Spurious "broken pipe" error messages, when used in typical UNIX shell pipelines #46016
• https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem

Naming convention

The naming follows the convention used by #![windows_subsystem = "windows|console"] where the values "windows" and "console" have the same names as the actual linker flags: /SUBSYSTEM:WINDOWS and /SUBSYSTEM:CONSOLE.

The names sig_ign and sig_dfl comes from the signal handler names SIG_IGN and SIG_DFL.

Steps

• Implement the feature:
  • Support #[unix_sigpipe = "inherit|sig_dfl"] on fn main() to prevent ignoring SIGPIPE #97802
  • Fix build with #[unix_sigpipe = "..."] support in rustc miri#2532
  • Change process spawning to inherit the parent's signal mask by default #101077 (made sigpipe::DEFAULT distinct)
  • Migrate rustc_passes diagnostics #102110 (improved diagnostics)
  • Add checks for the signature of the start lang item #106092
  • Regression test println!() panic message on ErrorKind::BrokenPipe #108980
• Use the attribute in a broad set of non-test-case places to learn how it works in practice.
  • #[unix_sigpipe = "sig_dfl"]
    • rustc: Use unix_sigpipe instead of rustc_driver::set_sigpipe_handler #102587
    • rustdoc: Use unix_sigpipe instead of rustc_driver::set_sigpipe_handler #103495
    • https://github.com/moonrepo/espresso/blob/e3f429b01bfd9a0a8956f11b1bc9120084c42d3c/crates/cli/src/main.rs#L18
    • https://github.com/trinitronx/intro-to-rust-kvstore/blob/2c26260a837c33f193cf26cecf49279675c3a6a3/src/main.rs#L8
  • #[unix_sigpipe = "sig_ign"]
  • #[unix_sigpipe = "inherit"]
• Remove rustc_driver::set_sigpipe_handler()
  • Remove rustc_driver::set_sigpipe_handler() #103536
• Add a test for #[unix_sigpipe = "inherit"] that test that the disposition is actually inherited, rather than assuming SIG_DFL shall always be inherited.
• Final comment period (FCP)
  • Stabilize #[unix_sigpipe = "sig_dfl"] on fn main() #120832
• Stabilization PR
  • Stabilize #[unix_sigpipe = "sig_dfl"] on fn main() #120832

Unresolved Questions That Blocks Stabilisation

• How can we make it easy to put fn lang_start() in an external crate that can be compiled with stable?
• We should rename the attribute and attribute values to things that reflect what they do rather than how they do it.

• #[unix_sigpipe = "sig_dfl"]
  • None
• #[unix_sigpipe = "sig_ign"]
  • currently child processes get SIG_IGN, but arguably they should get SIG_DFL since that is what most programs assume, and we explicitly made it that way before.
    • Note that we can implement this without running code right before exec, see DRAFT: Use a noop SIGPIPE handler instead of SIG_IGN #121578 for the trick.
  • Should the current default be implemented with a noop signal handler?
• #[unix_sigpipe = "inherit"]
  • Is the name clear enough? Maybe rename to unchanged?

Unresolved Questions That Does Not Block Stabilisation

Because these questions can be resolved incrementally after stabilization.

• What is the long-term plan with regards to changing the default behaviour with regards to ignoring SIGPIPE, if we want to do it at all?
  • Should Rust still ignore SIGPIPE by default? #62569

Resolved Questions

• We don't want to change to a -Z unix_sigpipe flag instead, see https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem/near/285499895, at least not initially.
• Should we only have the third sigpipe: u8 argument to fn lang_start() on Unix platform via cfg?
  Answer: No, this is not allowed, see top level comment in https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/pal.rs
• Should we stabilize sig_dfl or is inherit and sig_ign sufficient?
  Answer: There are noteworthy examples of real projects that has opted to use SIG_DFL to solve the BrokenPipe problem. Notably rustc itself. So if we don't stabilize sig_dfl, such projects can't make use of our new attribute. Therefore, we also need to stabilize sig_dfl.
• Should the attribute go on fn main() or on the top-level module (#![unix_sigpipe="..."])?
  Answer: It makes a lot of semantic sense to have the attribute on fn main(), because it is a way to configure what the Rust runtime should do before fn main() is invoked. For libraries, no entry point code that modifies SIGPIPE is generated, so allowing the attribute in these situations does not make much sense. See Change process spawning to inherit the parent's signal mask by default #101077 (comment) for small-scale discussion.
• Can we write the code in a way that allows lto to remove the _signal stub code completely? With a bool it works (see Support #[unix_sigpipe = "inherit|sig_dfl"] on fn main() to prevent ignoring SIGPIPE #97802 (comment)), but with the current u8 we might need to do some tweaks. Answer: There are currently 4 values and I see no feasible way to reduce it to 2.
• Can and should we alter the BrokenPipe error message and make it suggest to use the new attribute? Answer: No, because that would mean we would end up giving developer advice to users that can't act on the advice.
• Does this have any impact on defining a stable ABI? Answer: No, because ABI discussion are about enabling things such as calling Rust functions in binary artifacts produced by an older Rust compiler than the current one. That we changed the ABI of fn lang_start() is not relevant. And a stable Rust ABI is not even close (see Define a Rust ABI rfcs#600).
• Can we use MSG_NOSIGNAL with send() etc instead of setting SIGPIPE globally? Answer: No, because there is no equivalent for write(), and it would incur an extra syscall for each write-operation, which is likely to have significant performance drawbacks.

Disclaimer: I have taken the liberty to mark some questions resolved that I find unlikely to be controversial. If you would like me to create a proper discussion ticket for any of the resolved or unresolved questions, please let me know!

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

@rustbot label +T-libs

[jstarks]

Modified idea: instead of specifying SIG_IGN, std could register a SIGPIPE handler that does something like received_sigpipe = true. When inherit_sigpipe is called, it would switch back to the original disposition. After this, if received_sigpipe is true, then it would call raise(SIGPIPE). That way, the signal is not lost, just delayed, which is allowed by the specification.

This has the added advantage that we no longer need to remember to revert SIGPIPE to SIG_DFL when execing a process, since this happens automatically for caught signals. This would be an observable change for programs calling exec without using std::process, though, since they get SIG_IGN today.

[Enselic]

fn lang_start() and sigpipe: u8

I fully support the long-term goal of allowing any crate to define fn lang_start(). And I agree we can't have the sigpipe: u8 argument on fn lang_start() if we stabilize its signature for that purpose.

As long as there is only one fn lang_start() to choose from, I think the best approach is to parameterize its SIGPIPE behavior.

However, if one of many fn lang_start() can be chosen, we don't need any sigpipe: u8 parameter any longer. Instead, different implementations can be chosen. I imagine it would work similar to how choosing panic strategy works, where we currently have both
libpanic_abort-84c045833028a0b3.rlib and libpanic_unwind-5c5363659220970d.rlib in the sysroot, and which one that is chosen is controlled by the codegen flag -Cpanic=....

Similarly, I think we could add support for something like -Cruntime=sigpipe_kills which would link against liblangstart_sigpipe_sig_dfl-625a57f.rlib. With such a mechanism, we would not need any sigpipe: u8 parameter in the fn lang_start() signature.

Edit: After thinking some more on the next steps, I think the natural next step is to get rid of the sigpipe: u8 parameter to fn lang_start() already now. I will look into it.

The UI

Separately from above is the question of the UI for this. Should we use an attribute on fn main() or only a compiler flag?

When this was discussed previously the preference was to have an attribute so that the source code on its own defines the behavior of the program as much as possible.

But if you prefer a compiler flag instead @m-ou-se I would be happy to change to that. Would you prefer me to change it?

[jstarks]

Could you have the Unix lang_start call some function rust_setup_sigpipe, defined with weak linkage to call signal(SIGPIPE, SIG_IGN)? And then have the attribute redefine it with strong linkage to be a no-op?

If it works, it would:

1. Give us the attribute-based UI (which I think is acceptable to people).
2. Eliminate the parameter from lang_start immediately.
3. Have optimal performance (maybe with one additional call if LTO can't see through weak references).

(By the way, here I'm assuming that we only stabilize an attribute that skips all SIGPIPE configuration altogether ("inherit"), rather than stabilize a SIG_DFL option. Anyone asking for SIG_DFL really wants "inherit". And if I'm wrong about that, well, you they always get SIG_DFL on their own if they have "inherit". But the reverse is not true--if Rust doesn't offer "inherit", then there's no way to get it after the fact.)

[jpmckinney]

For anyone else seeing this on nightly:

error: cannot find attribute `unix_sigpipe` in this scope
   --> src/main.rs:137:3
    |
137 | #[unix_sigpipe = "sig_dfl"]
    |   ^^^^^^^^^^^^

error[E0635]: unknown feature `unix_sigpipe`
 --> src/main.rs:1:12
  |
1 | #![feature(unix_sigpipe)]
  |            ^^^^^^^^^^^^

It seems like this feature is gone and is replaced with a compiler flag: #124480

Note that when doing a web search for these language features or compiler flags, it's not obvious which version of the Unstable Book you're looking at.

Nightly: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/on-broken-pipe.html
Beta: https://doc.rust-lang.org/beta/unstable-book/language-features/unix-sigpipe.html