On Sun, 21 Jan 2001 17:28:49 -0500, Dan Sugalski wrote:
>The issue of 'which thread' comes in with signals. We can tell with real
>async events, since they'll have thread ownership tags on them if we care,
>but we can't do that with signals, and then we have the issue of "which
>thread" to deal with?
Here's how I've dealt with signals in a cooperatively threaded Perl
library. This design probably is too simple for Perl6, but it might
be useful to consider.
The library maintains threads' parent/child relationships. Each
thread is something of a session leader for the threads beneath it, at
least where signals are concerned. Signal events arriving at a thread
are first propagated to its children, and this repeats recursively
down to the leaf nodes on the family tree. In essence, signal
delivery happens from the leaf threads back up to the ancestors they
were originally destined for.
Operating system signals are posted to the library's "kernel", which
is the ultimate ancestor of every thread. This effectively (although
perhaps not efficiently) broadcasts OS signals to every thread.
The library's kernel decides which signals are fatal. It can do this
because it's also the event dispatcher. Threads that don't handle
fatal signals are stopped. Each thread has a destructor, so
everything gets a chance to clean up, even after fatal signals.
The library has an extra signal class: nonmaskable. Every thread that
receives a nonmaskable signal is stopped regardless whether it handled
the signal. Nonmaskable signals tend to be fictitious. They are
generated by the library itself, and they're usually meant to signal a
global shutdown. Two examples:
UIDESTROY is broadcast when a GUI's main window is closed. The user
wants this program to stop, and so it shall.
ZOMBIE is broadcast when every thread has stopped running, and nothing
is available to restart them. Imagine two threads playing ping-pong
with an event. If one drops the ball, both threads' callbacks keep
them alive. A program can detect when it has no more balls in play
(the queued-event counter is 0) and shut itself down. (It's a little
more involved than this: Watched filehandles are significant, for
example, so there's a counter for those, too.)
Here are two things Perl6 can do that my library doesn't, but I'm
going to recommend against them in a moment.
Perl6 will know which thread forked which process; it can track
this information to send SIGCH?LD to appropriate threads.
The system's SIGPIPE can be ignored altogether. Wherever a PerlIO
function returns EPIPE, it can also post SIGPIPE to the same thread.
I haven't implemented thess is my library because they preclude the
ability to set global SIGCHLD or SIGPIPE handlers in some totally
unrelated thread. Someone out there will want to do this, and it
might just be me. It helps that these tend to be "survivable"
signals; only the interested threads will ever notice them even when
they're broadcast everywhere.
Apropos of Perl 5: I've experimented long and hard on the language
level in perl 5, and I have a test case for detect them without using
handlers. It's unreliable though. That is, it may miss duplicate
signals between checks. When is this an issue, though?
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
