Skip to content

Bad handling of thread join deadlock in standard library #34971

Closed
@eefriedman

Description

@eefriedman
use std::sync::mpsc::Sender;
use std::sync::mpsc::Receiver;
use std::thread::JoinHandle;
fn main() {
    let (c1s, c1r) = std::sync::mpsc::channel::<JoinHandle<_>>();
    let (c2s, c2r) = std::sync::mpsc::channel::<JoinHandle<_>>();
    let (c3s, c3r) = std::sync::mpsc::channel::<()>();
    let t1 = std::thread::spawn(move || {
        let () = c1r.recv().expect("D").join().expect("A");
    });
    let t2 = std::thread::spawn(move || {
        let () = c2r.recv().expect("E").join().expect("B");
        c3s.send(());
    });
    c1s.send(t2);
    c2s.send(t1);
    c3r.recv().expect("C");
}

Gives (on playground):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:325
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<unnamed>' panicked at 'B: Any', ../src/libcore/result.rs:785
thread '<main>' panicked at 'C: RecvError', ../src/libcore/result.rs:785

There are two problems here:

  1. The error message is absolutely terrible.
  2. For the sake of safety, we might need to do something other than panic if this happens. This could affect crates which require that join() never returns early, like crossbeam.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions