|Anonymous | Login||2020-01-24 17:43 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000140||[1003.1(2004)/Issue 6] System Interfaces||Comment||Enhancement Request||2009-09-01 12:13||2013-04-16 13:06|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||See Note: 0000369|
|Summary||0000140: Realtime signals delivery order|
I confronted with real-time signals delivery problem. POSIX, as I could understand specification text, unambiguously appoints queuing and delivery order of real-time signals with lowest signal number first. But in reality it is not always so. Perhaps R.Stevens was first who revealed opposite to POSIX r-t signal delivery order in Solaris 2.6 . Later similar r-t signal behavior was detected in QNX Neutrino 6.2.1 .
I tried to clear up this issue for latest releases of POSIX-oriented OS that are available for me.
My test program was similar to program used by authors of book  (look file s5.cc in directory “signal” of archive http://www.books.ru/library/qnx-unix/pthread.tgz). [^] The core of test program: main process spawns daughter process using fork() function and then works in parallel with it. Daughter process masks r-t signals and prepare to receive them using sigaction(). Among other sigaction() register signal catching function that prints the number of delivered signal and its value. After short time parent sends r-t signals to daughter in order from SIGRTMAX to SIGRTMIN. After that daughter unmask all r-t signals and receives them. Each signal is sent in series with 3 different values. If r-t signals behavior conforms POSIX, signals are received in order from SIGRTMIN to SIGRTMAX, signal values are received in order they were sent.
The results of program running in some POSIX-oriented OS are different. OS LynxOS 4.0 shows exactly r-t signal behavior as prescribed in POSIX standard - first signals with lower numbers are delivered and signals with the same number are delivered in FIFO order. OS Solaris 10 and QNX Neutrino 6.4.1 deliver r-t signals in inverse order, that don’t conform POSIX.
Since I work mainly with QNX Neutrino OS, I tried to clear up this issue, and after I found nothing in OS documentation I turned to Neutrino developers for explanation. In there reply it was stated that test program has a bug: so as to receive r-t signals according to POSIX prescribed order r-t signals must additionally be masked in structure sigaction. Indeed this recommendation solved the problem: both OS – Solaris and Neutrino showed r-t signal delivery order from SIGRTMIN to SIGRTMAX.
1.W.Richard Stevens. UNIX Network Programming vol.2, Interprocess Communications, 2nd Edition.
2.Цилюрик О., Горошко Е. QNX/UNIX: анатомия параллелизма. (book in Russian) http://www.symbol.ru/alphabet/357604.html. [^]
|Desired Action||It seems to me it would be useful for programmers and OS developers if POSIX standard developers will append some information about additional r-t signal masking so as ensure right r-t signal delivery order (is masking unconditionally necessary XOR it not necessary at all XOR it is implementation defined), otherwise from time to time it may arise problems with program portability among POSIX-oriented OS. In my opinion appropriate information should be placed in “Signal Concepts”, function sigaction() description and may be in some other places.|
The need to set sa_mask fields appropriately to ensure signal handlers
are executed in the correct order is already noted in the Signal Concepts
rationale, XRAT6 B.2.4.2 Realtime Signal Generation and Delivery, near
the end (line 4059 in the 2004 edition):
"Given the specified selection of the lowest numeric unblocked
pending signal, preemptive priority signal delivery can be
achieved using signal numbers and signal masks by ensuring that
the sa_mask for each signal number blocks all signals with a
higher numeric value."
(It would probably be more correct for this to say "signal handling"
rather than "signal delivery". Conforming systems always deliver
(or behave as if they deliver) the signals in the right order, it's
just that without appropriate masking the first handler to be called
might not execute any code before being interrupted by the second
signal, and so on.)
|Thank You for reply. But as I can understand Rationale is only justification of specification statetsments. Based on my (little) experience I can say that it is more important for programmer read functions description and correctly use functions in his program than read rationale to understand why one or another decision was selected by standard developers and how this decision can or cannot be implemented. In my opinion function descriptions are more important also for OS developers. Very often OS developers word for word reproduce functions descriptions taken from standard in there OS docs, and nothing from standard rationales. So if additional realtime signal masking will evidently be written in sigaction() description, very likely it will be reproduced in OS documentation. Otherwise realtime signals handling misunderstanding/misusing in several OSes will continue it's long history and it seems to me this situation will appears in future.|
edited on: 2009-09-24 16:27
Would a pointer to the rationale from the sigaction() application usage here provide the information you think is needed?
Don Cragun (manager)
Add a paragraph to the Application Usage section of sigaction() after Issue 7, P1919, L61064:
See also rationale for Realtime Signal Generation and Delivery in Section B.2.4.2 on page x.
|2009-09-01 12:13||Nolik||New Issue|
|2009-09-01 12:13||Nolik||Status||New => Under Review|
|2009-09-01 12:13||Nolik||Assigned To||=> ajosey|
|2009-09-01 12:13||Nolik||Name||=> Nolik|
|2009-09-01 12:13||Nolik||Section||=> Signal Concepts|
|2009-09-01 12:13||Nolik||Page Number||=> 1|
|2009-09-01 12:13||Nolik||Line Number||=> 1|
|2009-09-01 14:59||geoffclare||Note Added: 0000211|
|2009-09-01 16:54||Nolik||Note Added: 0000212|
|2009-09-24 16:26||msbrown||Note Added: 0000242|
|2009-09-24 16:27||msbrown||Note Edited: 0000242|
|2010-01-07 16:15||Don Cragun||Interp Status||=> ---|
|2010-01-07 16:15||Don Cragun||Note Added: 0000369|
|2010-01-07 16:15||Don Cragun||Status||Under Review => Resolved|
|2010-01-07 16:15||Don Cragun||Resolution||Open => Accepted As Marked|
|2010-01-07 16:16||Don Cragun||Final Accepted Text||=> See Note: 0000369|
|2010-09-03 20:42||Don Cragun||Tag Attached: tc1-2008|
|2013-04-16 13:06||ajosey||Status||Resolved => Closed|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|