Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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
Reporter Nolik View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Nolik
Organization
User Reference
Section Signal Concepts
Page Number 1
Line Number 1
Interp Status ---
Final Accepted Text See Note: 0000369
Summary 0000140: Realtime signals delivery order
Description 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 [1]. Later similar r-t signal behavior was detected in QNX Neutrino 6.2.1 [2].
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 [2] (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.
Tags tc1-2008
Attached Files

- Relationships

-  Notes
(0000211)
geoffclare (manager)
2009-09-01 14:59

 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.)
(0000212)
Nolik (reporter)
2009-09-01 16:54

 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.
(0000242)
msbrown (manager)
2009-09-24 16:26
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?
(0000369)
Don Cragun (manager)
2010-01-07 16:15

 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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker