Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support #[unix_sigpipe = "inherit|sig_dfl"] on fn main() to prevent ignoring SIGPIPE #97802

Merged
merged 5 commits into from
Sep 2, 2022

Conversation

Enselic
Copy link
Member

@Enselic Enselic commented Jun 6, 2022

When enabled, programs don't have to explicitly handle ErrorKind::BrokenPipe any longer. Currently, the program

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

will print an error if used with a short-lived pipe, e.g.

% ./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 backtrace

by enabling #[unix_sigpipe = "sig_dfl"] like this

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

there is no error, because SIGPIPE will not be ignored and thus the program will be killed appropriately:

% ./main | head -n 1
hello world

The current libstd behaviour of ignoring SIGPIPE before fn main() can be explicitly requested by using #[unix_sigpipe = "sig_ign"].

With #[unix_sigpipe = "inherit"], no change at all is made to SIGPIPE, which typically means the behaviour will be the same as #[unix_sigpipe = "sig_dfl"].

See #62569 and referenced issues for discussions regarding the SIGPIPE problem itself

See the this Zulip topic for more discussions, including about this PR.

Tracking issue: #97889

@rust-highfive
Copy link
Collaborator

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 6, 2022
@rust-highfive
Copy link
Collaborator

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 6, 2022
@rust-log-analyzer

This comment has been minimized.

@Enselic

This comment was marked as outdated.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 6, 2022
@Enselic Enselic mentioned this pull request Jun 8, 2022
23 tasks
@Enselic Enselic changed the title Add feature no_ignore_sigpipe to never start ignoring SIGPIPE Add attribute #![no_ignore_sigpipe] to stop libstd from ignoring SIGPIPE Jun 8, 2022
@Enselic Enselic changed the title Add attribute #![no_ignore_sigpipe] to stop libstd from ignoring SIGPIPE Add attribute #![ignore_sigpipe(no)] to stop libstd from ignoring SIGPIPE Jun 9, 2022
@Enselic Enselic force-pushed the add-no_ignore_sigkill-feature branch from 2cf4a23 to cf341ec Compare June 9, 2022 17:03
@Enselic Enselic changed the title Add attribute #![ignore_sigpipe(no)] to stop libstd from ignoring SIGPIPE Add bin crate attribute #![sigpipe_handler(unchanged)] to prevent libstd from ignoring SIGPIPE Jun 10, 2022
@Enselic Enselic force-pushed the add-no_ignore_sigkill-feature branch from 87ea353 to fe3f47d Compare June 10, 2022 20:14
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Enselic
Copy link
Member Author

Enselic commented Jun 10, 2022

I consider this PR feature complete now. I'm sure there is more bike-shedding to do on what to call the attribute, and I'm sure you'll find things to comment on, but I'm happy with the implementation and the scope of the tests I added. I need to add a section to the unstable book, but I would prefer to do that after the bike-shedding is done.

Looking forward to a new code review round. If you want to me to split out some parts into separate PRs that would be fine, just let me know.

I had to do a rebase and took the opportunity to squash all my commits together, but I have already added some more commits. I plan on squashing again next time I need to rebase.

I'm also adding T-lang as requested.

@rustbot label -S-waiting-on-author +S-waiting-on-review +T-lang

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 10, 2022
@Enselic Enselic force-pushed the add-no_ignore_sigkill-feature branch from 4c97eb7 to 2f738f9 Compare June 13, 2022 04:46
@Enselic Enselic changed the title Add bin crate attribute #![sigpipe_handler(unchanged)] to prevent libstd from ignoring SIGPIPE Support #[pipeable] on fn main() to prevent ignoring SIGPIPE Jun 13, 2022
@bjorn3 bjorn3 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 31, 2022
@rust-log-analyzer

This comment has been minimized.

@joshtriplett
Copy link
Member

My fault, sorry; I missed that the standard library was referring to the compiler, rather than the other way around.

I think we should just duplicate this and put a comment in each pointing to the other; it doesn't seem worth attempting to deduplicate.

@RalfJung
Copy link
Member

RalfJung commented Aug 31, 2022

An include! the other way around would be much less problematic, but would still make the compiler sources as distributed in the rustc-dev component incorrect. Not sure if this matters for anything except for getting RA support in projects like Clippy or Miri.

So, exposing them perma-unstable would IMO be preferable over include!.

But yeah duplicating these 4 constants might not be so bad.

@Enselic
Copy link
Member Author

Enselic commented Aug 31, 2022

Thank you for further input, looking forward to another review round! I have addressed the comments now.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 31, 2022
@joshtriplett
Copy link
Member

New version looks good to me. @RalfJung?

@Enselic
Copy link
Member Author

Enselic commented Sep 2, 2022

From what I can tell, the newly raised concerns have been addressed in a satisfactory way (please correct me if I'm wrong @RalfJung!), so let's try again to get this merged.

@bors r=joshtriplett

@bors
Copy link
Contributor

bors commented Sep 2, 2022

📌 Commit 3810d4a has been approved by joshtriplett

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 2, 2022
@bors
Copy link
Contributor

bors commented Sep 2, 2022

⌛ Testing commit 3810d4a with merge 8c6ce6b...

@bors
Copy link
Contributor

bors commented Sep 2, 2022

☀️ Test successful - checks-actions
Approved by: joshtriplett
Pushing 8c6ce6b to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 2, 2022
@bors bors merged commit 8c6ce6b into rust-lang:master Sep 2, 2022
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #97802!

Tested on commit 8c6ce6b.
Direct link to PR: #97802

💔 miri on windows: test-fail → build-fail (cc @oli-obk @RalfJung).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Sep 2, 2022
Tested on commit rust-lang/rust@8c6ce6b.
Direct link to PR: <rust-lang/rust#97802>

💔 miri on windows: test-fail → build-fail (cc @oli-obk @RalfJung).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung).
@rustbot rustbot added this to the 1.65.0 milestone Sep 2, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8c6ce6b): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.8% [-0.8%, -0.8%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.7% [3.7%, 3.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.8% [-8.3%, -2.1%] 5
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
2.4% [2.2%, 2.6%] 2
Regressions ❌
(secondary)
2.4% [2.4%, 2.4%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.4% [2.2%, 2.6%] 2

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

@Enselic
Copy link
Member Author

Enselic commented Sep 3, 2022

📣 Toolstate changed by #97802!

Tested on commit 8c6ce6b. Direct link to PR: #97802

💔 miri on windows: test-fail → build-fail (cc oli-obk RalfJung). 💔 miri on linux: test-pass → build-fail (cc oli-obk RalfJung).

Fixed by rust-lang/miri#2532

(I already pinged oli-obk and RalfJung, so I removed @ from the quote above)

@Enselic Enselic deleted the add-no_ignore_sigkill-feature branch September 3, 2022 04:52
bjorn3 pushed a commit to bjorn3/rust that referenced this pull request Oct 23, 2022
…, r=joshtriplett

Support `#[unix_sigpipe = "inherit|sig_dfl"]` on `fn main()` to prevent ignoring `SIGPIPE`

When enabled, programs don't have to explicitly handle `ErrorKind::BrokenPipe` any longer. Currently, the program

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

will print an error if used with a short-lived pipe, e.g.

    % ./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 backtrace

by enabling `#[unix_sigpipe = "sig_dfl"]` like this

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

there is no error, because `SIGPIPE` will not be ignored and thus the program will be killed appropriately:

    % ./main | head -n 1
    hello world

The current libstd behaviour of ignoring `SIGPIPE` before `fn main()` can be explicitly requested by using `#[unix_sigpipe = "sig_ign"]`.

With `#[unix_sigpipe = "inherit"]`, no change at all is made to `SIGPIPE`, which typically means the behaviour will be the same as `#[unix_sigpipe = "sig_dfl"]`.

See rust-lang#62569 and referenced issues for discussions regarding the `SIGPIPE` problem itself

See the [this](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem) Zulip topic for more discussions, including about this PR.

Tracking issue: rust-lang#97889
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet