On Tue, Jun 18, 2013 at 4:44 PM, Glenn Fowler <[email protected]> wrote: [snip] > this is from the linux signal(7) > it contrasts the realtime signals RTMIN..RTMAX from the other "standard" > signals > > Real-time signals are distinguished by the following: > > 1. Multiple instances of real-time signals can be queued. By > contrast, if multiple instances of a standard signal are > delivered while that signal is currently blocked, then only one > instance is queued. > > 3. Real-time signals are delivered in a guaranteed order. Multiple > real-time signals of the same type are delivered in the order > they were sent. If different real-time signals are sent to a > process, they are delivered starting with the lowest-numbered > signal. (I.e., low-numbered signals have highest priority.) By > contrast, if multiple standard signals are pending for a process, > the order in which they are delivered is unspecified. > > { USR1 USR2 } are standard signals > while the respective signal handler is executing the signal is blocked > (1.) means that if a bunch of USR1's arrive while USR1 is being handled > all but one are dropped (in other words, only one of many is queued) > > so for a test with a storm of USR1's one would expect a wide range of > values for a USR1 caught counter -- such a test should use RTMIN..RTMAX > for deterministinc results -- determinism seems to be the rationale for > adding RTMIN..RTMAX in the first place
Erm... there is another issue which has to be carefully crafted into testing. It seems it's not safe to use more than "SIGQUEUE_MAX" signals concurrently (for obvious reasons (e.g. to conform to POSIX, avoid DOS attacks against the kernel etc.)), e.g. not more than 5632 signals "in flight" on SuSE 12.3/AMD64/64bit: -- snip -- $ ksh -c 'builtin getconf ; getconf SIGQUEUE_MAX' 5632 -- snip -- For 256 worker processes this leaves "only" 22 signals... -- snip -- $ ~/bin/ksh -c 'print -- $(( 5632 / 256. ))' 22 -- snip -- ... which AFAIK must be shared between the communication signals (e.g. SIGRTMIN-SIGRTMAX), SIGCHLD and maybe something else (e.g. SIGPIPE, SIGCONT etc.). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
