>>>>> "HZ" == Hong Zhang <[EMAIL PROTECTED]> writes:
HZ> There is no need to store pending signals. It will be impossible
HZ> to achieve in a multi-threaded perl runtime.
HZ> The only safe signals in multi-threaded system is using to use
HZ> sigwaitinfo() for all process-wide signals. So there will be
HZ> one dedicated thread waiting on sigwaitinfo() and it calls
HZ> signal handler when it retrieve a signal. All other threads
HZ> will block process-wide signals. We should only use regular
HZ> signal handler for synchronous exception handling, such as
HZ> SIGSEGV and SIGBUS.
my concept already assumes a single thread handling process level
signals. or at least only one thread is designated to handle any given
signal. but you can still get multiple signals and they have to be
recieved and stored before they can be delivered. this is true in a
simple process or in multithreaded one. there will possibly be an option
to compress multiple signals to a single delivered one. in general real
signals will just bump a special global counter in the event loop and
get delivered (which decrements the counter) at the next available
opportunity which depends on the selected delivery method.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
