> But sigwait is not a function specified with an EINTR error number.
> As I said before, this does not mean that EINTR cannot be returned.
> But it will create havoc among programs and it causes undefined
> behavior wrt to SA_RESTART. I think it is best to not have any
> function for which EINTR is not a defined error to fail this way.
> This causes the least amount of surprises and unnecessary loops around
> the userlevel call sites.
We use the same rt_sigtimedwait system call for sigtimedwait and
sigwaitinfo, which do list EINTR for the case of a handled signal.
It's for this scenario that the system call gives EINTR in this case.
We could have libc's sigwait repeat the system call on EINTR.
Unfortunately it is already the case that stop signals cause signal
interruption of system calls when they should be restarted.
rt_sigtimedwait is no different from other system calls in this regard.
It's a general problem. There is a signal wakeup in order to process the
stop signal. The blocking system call wakes up diagnoses this with EINTR.
In the case of a handled signal, this gets to the handler setup and the
first thing that does is the SA_RESTART processing. But when the signal
instead causes a stop (for job control or ptrace) and a later resumption
without running a signal handler, no restart happens. In the case of the
sleep calls, this causes early wakeups. In other blocks it produces the
spurious EINTR returns.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |