4 ms·
This seems rather like a hole in the scheme. There really are thread-unsafe functions like `setlocale` or `setupterm`, and the corresponding Rust crates allow y
by ridiculous_fish 5y ago
This seems rather like a hole in the scheme. There really are thread-unsafe functions like `setlocale` or `setupterm`, and the corresponding Rust crates allow you to use these functions from arbitrary threads. It's easy to produce a SIGSEGV by just invoking `ncurses::initscr()` a bunch in separate threads, without writing any unsafe code.
- firethief 5y agoThat's only a problem if you use code that is unsound. Well-written crates do not incorrectly mark functions safe.
- pornel 5y agoThread-unsafe C functions are a problem for Rust indeed. For example, C `setenv()` is unfixably broken for multi-threaded programs, and C code invoking it can crash Rust programs. Currently it's an open question what Rust should do about that. However, for Rust functions there's no hole, because Rust doesn't allow thread-unsafe global state. All globals always have to be immutable or use some synchronization primitive. Therefore, a safe Rust version of the `setlocale()` function would be forced to use atomics or mutexes to set the locale without data races. It's still a bad API, and Rust can't fix that.