home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: lts@westford.ccur.com (Lee Schermerhorn)
-
- >Submitted-by: rcollins@encore.com (Roger Collins)
- >
- >Do signals preempt a user's signal handler?
- >
- >In other words, you're in a user signal handler, a signal is delivered
- >which is caught and unblocked, does it preempt the currently running
- >signal handler to run the signal handler for the new signal? if it
- >is a lower numbered signal?
-
- Yes -- just as in Posix.1 signals -- handlers do nest. It doesn't matter
- whether the new incoming signal is a lower number or not. If it is
- unblocked (and caught) at the time of generation, it will be delivered.
- The only new semantics that Posix.4 bring are:
-
- 1) a specification of queueing of multiple occurences of a signal. Posix.1
- leaves this implementation defined (1003.1-1990, sect 3.3.1.2, p.53,
- lines 463-464).
-
- 2) a specification of ordering of delivery when more than one signal is
- pending an unblocked: within the range of "realtime" signals defined
- by Posix.4, lower numbers are delivered first (the rationale explains
- why); the order outside of the "realtime" range is unspecifed. Posix.1
- left the ordering unspecified (op cit, lines 464-466).
-
- 3) a specification of the delivery of additional signal information.
- This was essentially lifted from the SVR4 "siginfo" behavior, with
- the addition of an application defined datum that can be passed with
- the signal.
-
- You might wonder if a subsequent occurence of a signal can preempt the
- signal handler for the same signal, causing it to be reentered. It could,
- but only if the application explicitly unblocked the signal from within
- the handler. When the signal is delivered, its signal number is
- automatically added to the process's current blocked signals mask.
-
- Lee Schermerhorn
- Concurrent Computer Corp
- Secretary, P1003.4 WG
- Technical Reviewer, P1003.4 various sections
-
-
- Volume-Number: Volume 31, Number 23
-
-