>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The issue of 'which thread' comes in with signals. We can tell
DS> with real async events, since they'll have thread ownership tags
DS> on them if we care, but we can't do that with signals, and then we
DS> have the issue of "which thread" to deal with?
DS> All the synchronous signals I know of are fatal, and all the async
DS> ones won't tell us which thread. And, of course, there are the
DS> ones that may or may not be async (like SIGPIPE) for more fun. So
DS> while we *could* die from a signal handler, none of the ones we
DS> can catch can be associated with a thread. This isn't the case for
DS> non-signal signals like the die and warn handlers, but they're not
DS> strictly speaking signal handlers.
my view is that each thread gets its own interpreter and as such gets
its own event loop (working with the assumption that the op code loop is
tight (or the same) as the event loop). then the coder has the
obligition to request a signal event. when the real signal comes in,
perl guts sets/increments a global (and thread safe) counter. only those
interpreter threads/event loops looking for that signal will have it
delivered to them. so there is no issue about which thread gets a signal.
>> What about automatically having a dedicated signal handling thread for
>> any program that is user-level threaded?
DS> I'm torn between doing that and not, since firing up a second
DS> OS-level thread can add some overhead that we might not need with
DS> the "set a flag and check on op boundary" setup. I know that VMS
DS> won't kick over to the slower fully threadsafe version of its
DS> runtime libraries until you actually start a second thread, and I
DS> thought Solaris did something similar.
my scheme allows the user to do that. they just create a regular thread
and request all their signal events in that thread. but my design also
allows different threads to handle different signals (and multiple
threads to handle the same one).
in fact, i was working on a design a couple of years ago that was going
to share a single event loop among multiple c threads. i think that
isn't going to work here so the interpreter/event loop per thread
concept is best. by allowing any thread to handle any signal, we give
the coder maximal flexibility without tying perl guts to any thread
requirements. this would work the same on a non-thread OS as one which
has threads.
i am working on a proposal to handle socket and async file i/o in the
guts in a consistant way across any platform (supporting any combination
of those services) and it works well under this model. i should have it
written up in a couple of days.
my main point there is that faking async i/o and sync signal delivery is
much easier than faking threads. so we code all the internals to an
event loop api and fake it underneath as needed on various
platforms. much more on this soon.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
