Libs Meeting 2024-02-28

# Libs Meeting 2024-02-28 ###### tags: `Libs Meetings` `Minutes` **Meeting Link**: https://meet.jit.si/rust-libs-meeting-ujepnbwg2lzqgt6wvrndwimi **Attendees**: ... ## Agenda - Triage - Anything else? ## Triage ### FCPs 1 rust-lang/rust T-libs FCPs - merge rust.tf/115746 *Print thread ID in panic message if thread name is unknown* - (4 checkboxes left) [joshtriplett (1)](https://rfcbot.rs/fcp/joshtriplett), [m-ou-se (1)](https://rfcbot.rs/fcp/m-ou-se), [Amanieu (1)](https://rfcbot.rs/fcp/Amanieu), [the8472 (1)](https://rfcbot.rs/fcp/the8472) ### https://github.com/rust-lang/team/pull/1347 Should be added to `people/*.toml` Mara responded. ### (Backports) rust.tf/121646 *Fix race between block initialization and receiver disconnection* This bug has been around for more than a year on stable. Bug is only a memory leak. Not worth backporting. Mara responded. ### (Nominated) rust.tf/62569 *Should Rust still ignore SIGPIPE by default?* The 8472: This could also be a call at the start of main, if the default is 'nothing' (in an edition?). Mara: Changing the default in an edition would mean that `cargo fix --edition` would probably need to insert the attribute or function call into all programs, even though it's irrelevant to most people. Amanieu: four options: 1. do nothing. sigpipe will kill the process 2. ignore, and have child process inherit that ignored mode 3. ignore using an empty handler, such that a child process inherits the original setting 4. also ignore the error on write() to a broken pipe (instead of panic). JoshT: This is only relevant for when you have a Rust fn main, not if you're a Rust library JoshT: So you get different behaviour depending on whether Rust owns main or not Mara: I hate the attribute. I'd much prefer some function to call at the start of main. JoshT: If the default were to do nothing, then we could drop the attribute and people who want the other behavior could *call a function*. Mara: Yeah. I just hate having this magic attribute as an interface into a library (std), to inject a boolean into it. The 8472: This is a consequence of Rust having a runtime. JoshT: In general, we should minimize what we do before main. At least avoid anything that one might want to customize. JoshS: What do other tools/languages do? JoshT: systemd ignores SIGPIPE for daemons it launches. Amanieu: Go does something with sigpipe, not sure what. The 8472: Java also does something. Amanieu: Today's implementation in Rust sets it to ignore but remembers the original for subprocesses. JoshS: We should reset it to what we would have inherited, before spawning processes. JoshT: About changing the default in an edition, are there any concerns other than what mara mentioned? Mara: It's not a big concern. Maybe it is relevant to so few programs that it's fine if we don't automatically add the attribute/call, but just print a warning or something. Amanieu: Just changing it can cause subtle bugs, like in a rarely-printing service. The 8472: Only if the pipe is disconnected. Which is kind of weird. JoshT: The normal way this would happen in a server would be if the server started a subprocess, handed it a pipe, and then the subprocess exits. The 8472: Is there a way to disable sigpipe for a single fd? JoshT: Not for all unix. Amanieu: I think the breaking change is unacceptable, because it is too silent. JoshT: I think it'd suffice to put it in the edition guide. The 8472 + Mara: For `my-rust-program | head`, this is fine. But changing the behaviour for reading from subprocesses is bad. Mara: Should we try to ignore sigpipe only for the Command api for subprocesses? (If that's possible.) The 8472: can signal be masked on just the current thread, before read() from child? JoshS: The changed behaviour will surprise people. JoshT: The status quo surprises people too. Amanieu: Other edition changes are more loud Mara: There have been other edition changes where if you don't do `cargo fix --edition`, the code can silently mean something slightly different (e.g. different drop order). JoshT: We're coming up to the wire on making changes prior to the edition. Also, if we want to avoid needing the attribute, then we'd need to change the default. The 8472: If the default is inherit, then it doesn't make sense to do this as an attribute, because it can just be a simple function call. JoshS: Even without the default changing, we could have an API to reset back to the UNIX default. JoshT: Right, but then you're setting it and then un-setting it, which means there's still motivation for the attribute. Mara: There are more knobs you might want to tune about std, so I'd prefer a more generic solution than a really specific attribute like this. build-std I guess. Mara: This attribute makes `std` more special. If we ever stabilize providing an entrypoint in your own crate, that crate would have to accept the attribute too.. Amanieu: no consensus, let's revisit later. ### (Nominated) rust.tf/108277 *std::fs::Metadata timestamp methods will panic on files with invalid timestamp nsec values* Already discussed. Fix to be reviewed. Josh left a comment. ### (Regressions) rust.tf/119560 *\`cargo test\` performance regression on Windows on version 1.75.0* ### (Regressions) rust.tf/53340 *Performance regression in tight loop since rust 1.25* ### (Regressions) rust.tf/112180 *assertion failed: key as usize != KEY\_SENTVAL in DragonFly BSD* ### (Regressions) rust.tf/120537 `P-high` *miri: checked\_pow: overflowing shift by 64 in \`unchecked\_shl\`* ### (Regressions) rust.tf/121606 *regression: from\_raw\_parts is ambiguous* Closed; expected behavior when doing multiple glob imports. ## Actions - [ ] Reply to all issues/PRs discussed in this meeting, or add them to the [open action items](https://hackmd.io/Uehlc0qUQfWfvY1swYWRgQ). _Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_