Comment by npalli
6 days ago
Fearless concurrency with Rust unless you are worried about lifecycle management, threads/co-operation and general ergonomics. Even modern c++ might be better at this (gasp!) with std::jthread
6 days ago
Fearless concurrency with Rust unless you are worried about lifecycle management, threads/co-operation and general ergonomics. Even modern c++ might be better at this (gasp!) with std::jthread
Are there any languages that provide for or care about lifecycle management across address space boundaries? After fork() you're usually fucked and need explicit controls.
Pythons multiprocessing comes to mind
I believe Rust's std::thread::scope is an equivalent.
> Unlike non-scoped threads, scoped threads can borrow non-'static data, as the scope guarantees all threads will be joined at the end of the scope.
> All threads spawned within the scope that haven’t been manually joined will be automatically joined before this function returns.
So, std::jthread is basically fixing std::thread. In C++ it's difficult to fix broken standard library features so they just make a new thing and discard the old busted one. Landfill programming.
The fact Rust actually has scoped threads is unrelated, in Rust they can do this because they have working lifetime checking and in C++ such a feature would be meaningless, you're always assumed to have manually ensured the correct lifetimes and they aren't checked.
Generously you could say they're gesturing at the fact C++ decided to bolt the stop flag mechanic to jthreads, so you can have the old broken threads or this newer non-broken threads which also has built-in stop flags. But that's less choice, it's not as though you can't have a stop flag in Rust.
Ok, but I am literally getting filtered by installing C++ libraries. I haven't accomplished anything in the last 5 days other than determine that the previous libraries are not usable.
Heretic!
Yes, and if you update to a version of LLVM that was released literally a week ago, jthread exists.