[OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

Rich Felker dalias at aerifal.cx
Fri Aug 19 20:44:53 UTC 2011


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


More information about the busybox mailing list