posted morning of Thursday, August 20th, 2009
➳ More posts about Programming
➳ More posts about Programming Projects
➳ More posts about Projects
This is one of the changes to *nix made to accomodate multi-threading; there is now one errno per thread.
Personally, I favor rfork() over the POSIX threading model, which is an incredibly fruitful source of bugs.
posted morning of August 20th, 2009 by Randolph
I don't know about rfork -- I should find out about it. I did not realize errno was allocated by thread, makes sense -- so that's why I don't have to enclose api calls and errno checks in mutex.
posted morning of August 20th, 2009 by Jeremy
How is rfork different from fork()? I like threads because of the shared memory between the parent and the child, though obviously this is bug-prone. You're arguing against multithreaded processes in general?
posted morning of August 20th, 2009 by Jeremy
Looks like I'm safe (for some values of "safe")... rfork() system call does not appear to be implemented on my OS. (Linux v. 2.6.9-42.ELsmp/RedHat 3.4.6-2)
posted morning of August 20th, 2009 by Jeremy
rfork.
There's uses for threads, sure, but I wish they hadn't become an everyday tool--they make simple things very difficult. By and large I find the fork() model of process management hugely safer and more predictable than threading. Threading, as a retrofit, also messes up the Unix system call API (including errno, which started this thread), which was never designed to be reentrant.
posted morning of August 22nd, 2009 by Randolph