Nikolsky Oleg(deleted)
04/19/2009 8:57 AM
post27443
|
Realtime signals help information should be more accurate.
As stated in help topic on sigqueue() function, “Should any of multiple pending signals in the range SIGRTMIN to
SIGRTMAX be selected for delivery, the lowest numbered one is delivered.” This assertion complies with POSIX Realtime
Signal Concept (http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html): “When multiple unblocked
signals, all in the range SIGRTMIN to SIGRTMAX, are pending, the behavior shall be as if the implementation delivers the
pending unblocked signal with the lowest signal number within that range. No other ordering of signal delivery is
specified. If, when a pending signal is delivered, there are additional signals queued to that signal number, the signal
shall remain pending. Otherwise, the pending indication shall be reset.”
In fact, as shown in book “Цилюрик О., Горошко Е. QNX/UNIX: анатомия параллелизма.
ISBN 5-93286-088-X” (http://www.symbol.ru/alphabet/357604.html ), QNX Neutrino behaves opposite manner (look at file s5
.cc in archive pthread.tgz http://www.books.ru/library/qnx-unix/ ): while pending RT signals are delivered to process
using signal handler function, signals with highest numbers are received first. I attach slightly changed simple program
s5_sighandler.c that illustrates this behavior. The same order of signal delivery demonstrates sigsuspend() function in
conjunction with signal handler function.
On the other hand, if queued RT signals are not “delivered” but “accepted” (xsh_chap02_04.html terminology) by
process with sigwaitinfo() function, QNX Neutrino behaves in accordance with IEEE Std 1003.1, 2004 Edition - signals
with lowest numbers are delivered first. This is illustrated by s5_sigwaitinfo.c program.
It seems to me that RT signal help documentation require some refinement:
1) Neatly distinguish signal delivery and accepting in help topics. Explain what does signal catching means every time
this term appears in help topics.
2) Neatly describe the order of queued RT signals delivery and accepting as it is implemented by QNX Neutrino.
3) Neatly explain in sigwaitinfo() help topic that accepting signals must be blocked like it is written in sigwait()
help topic.
4) Bring help topics on concrete functions to conformity with chapter “The QNX Neutrino Microkernel”. For example, in
this chapter I read “The POSIX standard includes the concept of queued realtime signals. QNX Neutrino supports
optional queuing of any signal, not just realtime signals. The queuing can be specified on a signal-by-signal basis
within a process. Each signal can have an associated 8-bit code and a 32-bit value.. . . As a result, signals are
delivered in priority order with lower signal numbers having higher priority. This conforms with the POSIX standard,
which states that existing signals have priority over the new realtime signals. . . . The OS supports the 32 standard
POSIX signals (as in UNIX) as well as the POSIX realtime signals, both numbered from a kernel-implemented set of 64
signals with uniform functionality. While the POSIX standard defines realtime signals as differing from UNIX-style
signals (in that they may contain four bytes of data and a byte code and may be queued for delivery), this functionality
can be explicitly selected or deselected on a per-signal basis, allowing this converged implementation to still comply
with the standard. Incidentally, the UNIX-style signals can select POSIX realtime signal
queuing, if the application wants it.”
But help topic about sigqueue() function tells me: “Should any of multiple pending signals in the range SIGRTMIN to
SIGRTMAX be selected for delivery, the lowest numbered one is delivered. The selection order between realtime and
nonrealtime signals, or between multiple pending nonrealtime signals, is unspecified.”
Attachment: file signals.tar.gz, containing s5_sighandler.c s5_sigwaitinfo.c programs.
|
|
|