On Fri, Aug 19, 2011 at 10:03:40AM -0700, Cathey, Jim wrote: > >Threads are also purely a question of taste. Rich likes them. Lots > >of people like them. I don't. Alan Cox doesn't. YMMV. > > I'm torn. Sometimes good, sometimes bad. We're actually having > very good luck using them in our product at work, but that's because > it was a port from an OS whose processes were more like threads. > (Shared memory space.) Also, our main synchronization mechanism is > message-passing (via Linx), which is quite clean. We've had few > problems with this, but that's mostly because the gross bugs were > already shaken out years ago in the original OS. Starting from > scratch I would _not_ have used threads. Or very few threads at > least, rather than the 100+ that's in it now. > > The most evil fallout from threads was the necessity to eliminate > all forks in our program. 99% of the time it worked just fine, > but every once in awhile it crashed. We wasted man-months chasing
I agree, but the problem is not that the designers of pthreads were incompetent, it's that there are some fundamentally unsolvable issues (like who owns a process-shared mutex after fork? or what happens to semaphore counts?) that admit no general, transparent solution. The concept of fork is highly problematic with respect to any form of synchronization/locking, and this was already an issue with traditional multi-process synchronization tools (like file locks, SysV semaphores, or even things like O_EXCL or mkdir and using file creation/ownership as a lock). > that, it was some kind of conflict with glibc fork vs malloc. Ugh. This is supposed to be fixed, but there are possibly some hideous corner cases deriving from the fact that fork() is specified to be async-signal-safe but now has to deal with malloc state/locks... > So I had to invent a fork server (the Blue Rajah: Master of Cutlery, > Forks a Specialty :-), and get rid of all system/fork/popen calls. POSIX specifies that calling async-signal-unsafe functions after fork in a multi-threaded process results in UB, but makes no such rule for use of system/popen. As they have no reason to call anything but exec*() in the child, I think they should be perfectly safe even in multi-threaded programs. Certainly posix_spawn is safe. Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
