4 ms·
Correct. libc is largely thread unsafe.
by raggi 3y ago
Correct. libc is largely thread unsafe.
- masklinn 3y agoThread unsafe is too kind a qualifier, libc is largely thread-broken.
- cryptonector 3y agoDoesn't have to be. Even `strtok()`, `getpwnam()`, etc. can be thread-safe (just not reentrant).
- somat 3y agoI have to admit the conclusion I have reached is that threads are the problem not libc. We really should have embraced a better primitive than "shared memory execution environment"
- panzi 3y agoI think a lot could be fixed with functions that don't access global state, but get that state as an additional parameter. E.g. I would really like `snprintf_l()`/`fprintf_l()` to be supported by glibc. It is supported by FreeBSD, macOS (Darwin), and even Windows (with a `_` prefix for some reason)! Not by GNU libc.
- senkora 3y agoI think that it is generally not reasonable to convert existing large projects to be multithreaded, in the same way that it is generally not reasonable to fully rewrite existing large projects from scratch. The alternative that I have seen be successful, is to achieve parallelism by forking separate processes wherever you would have spawned threads, and then communicate through shared memory regions. It's a lot like having Rust-style unsafe blocks, in that you know that if you are having a thread-safety issue it will definitely be in one of the code sections where you are touching the shared memory region, and not anywhere else. Obviously there's a higher startup cost for forking, but this makes it possible to gain parallelism without breaking all the thread-unsafe code that is certainly in an existing large project.