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.