patacongo commented on issue #8899: URL: https://github.com/apache/nuttx/issues/8899#issuecomment-1484182384
> I have noticed that there are few more items to be checked: > > * `The default action for a real-time signal is to terminate the receiving process` -- I'm not sure that we have this > > * `Real-time signals are queued to the receiving process. This applies even when the same real-time signal is received multiple times. In contrast, if a standard signal is blocked and multiple instances of it are to be delivered to a process, only one becomes pending and the rest are discarded.` -- I think we can miss real-time signal if `sigwait` is called after signal is sent and signal is not blocked (`sighold()` is not called). That is confusing. It could be the same real time signal or any other signal: In any case, only a single signal handler can run at at time; a signal handler cannot be interrupted by another signal handler. So any signal handling action received while a signal handler is running has to pend in a queue. Blocked signals are always queued. The signal handler can run when the signal is unblocked. Multiple standard signals with the same number can be queued, can't they??? I would need a POSIX reference to understand why you say that. Signals that terminate the task will, of course cause all pending signals to be discarded. But things like SIGCHLD, the death-of-a-child signal could happen several times if child tasks exit synchronously. I think you not want to lose those events. The last time I looked, POSIX said the queuing of standard signals is optional. But again, we should probably clarify what POSIX means by queuing. In NuttX there is one queue for all pending signal actions; you seem to be implying a separate queue for each signal. > Should we have a separate issue for this? Up to you. We can fold that into this issue if you like; or you can create a new issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
