---
# System prepended metadata

title: Libs Meeting 2024-02-28
tags: [Minutes, Libs Meetings]

---

# 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)_
