At 10:56 AM 5/11/2001 -0700, Hong Zhang wrote:
> > >There is no need to store pending signals. It will be impossible
> > >to achieve in a multi-threaded perl runtime.
> >
> > No, it won't be that tough to get multiple pending signals for a thread.
> > Not "real" Unix signals, perhaps, but what look like them, more or less.
>If
> > several alarms time out essentially simultaneously, or some I/Os finish at
>
> > the same time, a thread could have a stack of things to look at.
>
>Suppose we are talking about real unix signals. Otherwise, we can use event
>loop for sending/processing event to do so.
Real Unix signals aren't going to get treated any differently from any
other event, though, so I'm not sure there's much to be gained from
treating them all that specially. They're just one more event to be fed
into a perl program. (The only really useful thing you can do with signals
that isn't really eventish is with alarm to interrupt a blocked system call
or something. But that doesn't work with threads, and has other issues, so
we'll be doing it a different way)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
