On Tue, Jun 18, 2013 at 5:05 PM, Roland Mainz <[email protected]> wrote: > 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.).
Ok... the assumption that |SIGQUEUE_MAX| can be used for any usefull calculations in this case seems to be wrong... ... because Solaris 11/SPARC returns this value: -- snip -- $ getconf SIGQUEUE_MAX 32 -- snip -- ... but still passes my SIGRT*-signal storm test with 512 child processes sending 4*8 signals each... ---- 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
