Messages in this thread | | | Date | Tue, 11 Feb 2003 19:13:33 -0800 | From | Roland McGrath <> | Subject | Re: another subtle signals issue |
| |
> You probably mean ERESTARTSYSNOHAND.
Indeed, that's the right one for functions like semop that are specified in 1003.1-2001 explicitly to wake up when a signal was caught. I read the SA_RESTART wording as not intending to apply to functions that say that explicitly.
> There are lots of system calls that simply are not restartable.
POSIX permits partial results for cases like read and write. Those aside, and leaving aside calls in uninterruptible sleeps (in which stops take place only after the sleep wakes), POSIX would seem to require that they be restarted when there is a job control stop and continue.
> > The reason I am concerned about this is that I think any case that is > > broken by the lack of the optimization in the patch below must also be > > broken vis a vis the semantics of stop signals and SIGCONT (when SIG_DFL, > > SIG_IGN, or blocked). POSIX says that when a process is stopped by > > e.g. SIGSTOP, and then continued by SIGCONT, any functions that were in > > progress at the time of stop are unaffected unless SIGCONT runs a handler. > > That is, nobody returns EINTR because of the stop/continue. > > This is what ERESTARTNOHAND does [...]
ERESTARTSYS and ERESTARTNOHAND only differ when a handler is run, which is not the case I am talking about.
> The old code tried rather hard to make signals that were truly ignored > (SIGSTOP/SIGCONT is not of that kind)
POSIX clearly specifies that stopping and continuing "shall not affect the behavior of any function" (when SIGCONT is SIG_DFL or SIG_IGN, or is blocked).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |