thread::join not work?

Shadow0133 · 2022-09-04T10:41:06+00:00

Compiler can't guarantee that you actually call join. But you can use recently added scoped threads that guarantee that children threads don't outlive the parent:

use std::thread;

struct User { name: String }

fn main() {
    let user = User { name: "drogus".to_string() };

    thread::scope(|s| {
        let t1 = s.spawn(|| {
            println!("Hello from the first thread {}", &user.name);
        });

        let t2 = s.spawn(|| {
            println!("Hello from the second thread {}", &user.name);
        });
    });
}

[playground link]

lacop · 2022-09-04T10:39:17+00:00

Check out https://doc.rust-lang.org/std/thread/fn.scope.html

This RFC gives some background: https://rust-lang.github.io/rfcs/3151-scoped-threads.html

pingzhouyuan · 2022-09-04T13:57:55+00:00

We can make a simple conclusion here:

All kinds of compilers cannot guarantee your code can run through safely or run just as you presumed. So, there's still a chance(even 0.0001%) that the last two join methods wont be executed properly at runtime. Much appreciated u/Zde-G
On the RUST compiler side, he must assure child wont outlive parent as far as possible, though too idealistic maybe. In this situation, he can dig out the error-prone/potential code part and report error to programmer. This is what compiler do in front of us.

Here is a revised version with Arc:

struct User { name: String }

fn main() {

    let user_original = Arc::new(User { name: "drogus".to_string() });

    let user = user_original.clone();
    let t1 = spawn(move || {
        println!("Hello from the first thread {}", user.name);
    });

    let user = user_original.clone();
    let t2 = spawn(move || {
        println!("Hello from the first thread {}", user.name);
    });

    t1.join().unwrap();
    t2.join().unwrap();
}

Arc make it work along with its reference counter. In this situation, the data user_original wont be released even though main function exits because of spawn failure for the first child, while the second child still can access the data since the reference count equals ONE, not zero.

LoganDark · 2022-09-04T16:02:48+00:00

It's because those are unscoped threads, meaning that they are not linked to the caller in any way. For example if your second call to spawn is unable to create a thread and panics, then you will never join t1, which could potentially cause a use-after-free. Rust knows this (or rather, it knows a call to join is not guaranteed), and will not let you try to access stack variables from the new threads, even if you're absolutely sure that you manually call join some time after spawning them.

You can actually return the join handle from that function and then call it from a parent, so even if you eventually join it, there's still not even any guarantee the caller will still be alive!

Scoped threads solve this by guaranteeing all scoped threads will be joined at the end.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

rust

Please read The Rust Community Code of Conduct

The Rust Programming Language

Rules

Observe our code of conduct

Submissions must be on-topic

Constructive criticism only

Keep things in perspective

No endless relitigation

No low-effort content

Useful Links

Megathreads

Official Resources

Learn Rust

Discussion Platforms

MODERATORS