Mattias Engdegård wrote:
> I don't think it's contrived --- writing not a byte, but the pid and
> return status of the dead child to a pipe is an old but useful trick.
> It gives a natural serialisation of child deaths, and also eliminates
> the common race where a child dies before its parent has recorded its
> pid in a data structure. See it as a safe way of converting an
> asynchronous signal to a queued event.
>
> Using pipes to wake up blocking select()s is a useful thing in general,
> and often a lot cleaner than using signals when dealing with threads.
This mistake is exactly the reason that Netscape 4.x freezes from time
to time on Linux.
It tries to write too many things to a pipe, making the assumption that
this will never happen.
The correct thing to do, which never freezes, is to maintain a queue or
other structure inside your own process. Just write a single byte to
the pipe when a condition flag becomes true for the first time, after
setting the flag (both inside the signal handler). Clear the flag and
handle the pending conditions whenever you read the byte in the select()
loop. A flag can be implemented as a pair of counters if you can't do
atomic sets and clears.
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:49 EST