From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
Description of problem:
The man page for sigwait() claims it will never return an error.
However I have a multi-threaded program that uses sigwait() and
occasionally an error of 4 (interrupted system call) is returned. This
is very hard to reproduce and does only happen rarely but according to
the doc we should not be getting errors from sigwait().
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Unfortunately I don't have a standalone test for this.
Well, the definite source is the standard, not man page.
Where I see:
lists at least EINVAL as allowed error.
Implementations may support additional errors not included in this list, may generate errors included in this list under
circumstances other than those described here, or may contain extensions or limitations that prevent some errors from
occurring. The ERRORS section on each reference page specifies whether an error shall be returned, or whether it may be
returned. Implementations shall not generate a different error number from the ones described here for error conditions
described in this volume of IEEE Std 1003.1-2001, but may generate additional errors unless explicitly disallowed for a
and sigwait description doesn't seem to explicitely disallow other
EINTR is specifically disallowed when not explicitly listed, for
functions in the Threads option. However, sigwait is not part of that
option, so the general clause Jakub cited does apply and the standard
permits returning EINTR here. It is reasonable to expect that this
will only occur when an unblocked signal arrived and was handled
without sigwait returning that signal. If there is a problem here, it
is a kernel problem. But it would require a reproducing program to
indicate whether the circumstances indicated a bug or a permissible
Reassigned to kernel, sigwait in libc is nothing but a little wrapper.
The kernel people can decide whether they want to close it as NOTABUG
or look into changing the kernel to never return EINTR which is not
The documentation should be updated to reflect a possible non-zero return code,