Hi Michael,
could you please look at
https://bugzilla.kernel.org/show_bug.cgi?id=58711
?
This part of man 7 signal
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.)
looks really confusing.
Yes, the kernel delivers (in fact, the task dequeus) them in order,
but this doesn't mean that the signal handlers will run in the same
order.
And let me repeat, whatever the kernel does, depending on the timing
kill(task, 62) + kill(task, 63) can "call" the signal handlers in any
order (as it seen by task). Unless this task plays with sa_mask or the
sender knows that at least SIG_63 is blocked.
Well. of course we could change dequeue_signal()->next_signal() so that,
say, SIG_63 will be chosen before SIG_62, this will "fix" the test-case.
But at the same time, this will break sigtimedwait().
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
