dbg! prints can tear in multi-threading code

[orlp]

This is technically not a bug, but simply a rather frustrating behavior. If you write dbg!(a, b), then the implementation doesn't take a lock on stderr for the entire debug print, but for a and b separately. This means that they can tear with other (debug) prints on stderr. E.g. if you have

 // Thread A.
let (a, b) = (1, 2);
dbg!(a, b);

 // Thread B.
let (a, b) = (3, 4);
dbg!(a, b);

You can see the output (or various other interleavings, it gets worse with more statements and more threads)

[src/some/path.rs] a = 3
[src/some/path.rs] a = 1
[src/some/path.rs] b = 4
[src/some/path.rs] b = 2

A workaround is to use dbg!((a, b)) but I'd rather we just fix the implementation to take a lock once for the entire dbg! call to make the entire debug print atomic.

[Mark-Simulacrum]

Nominating for T-libs-api decision. Today, dbg! takes the stderr lock when writing each line ([location] stringify!(x) = y), and does not hold the lock when computing the value (or values, in the case of dbg!(a, b, c).

There is a proposal in #149869 to precompute all values, then while holding the stderr lock print all three values. This avoids a concurrent thread interleaving its stderr writes in between the dbg! lines.

I'd like to get T-libs-api to decide what the locking semantics for multi-expression dbg! should be.

See also discussion here: #149869 (comment)

[orlp]

@dtolnay Reading the meeting notes of T-libs-api, it seems you suggested holding the stderr lock for the duration of the entire dbg!. This was my original angle as well, but I've come to realize that this is simply unacceptable (in my opinion). The reason is that this can cause incredibly easy deadlocks. Here is a very basic example that can deadlock if dbg! were to hold the stderr lock while computing the values:

// Thread 1.
dbg!("receiving", chan.recv());

// Thread 2.
dbg!("sending", chan.send(42));

The only reasonable path I see to non-tearing multi-input dbg! prints is to precompute all values before printing them. Regarding @the8472's point of 'at least printing something on a panic', that could be done with a drop handler if really desired, to at least print what was pre-computed.