Is pthread_cond_signal(3) man page correct?
yanegomi at gmail.com
Thu Mar 17 02:21:35 UTC 2011
On Wed, Mar 16, 2011 at 6:54 PM, David Xu <davidxu at freebsd.org> wrote:
> On 2011/03/16 23:23, Yuri wrote:
>> On 02/27/2011 18:00, David Xu wrote:
>>> I think in normal case, pthread_cond_signal will wake up one thread,
>>> but other events for example, UNIX signal and fork() may interrupt
>>> a thread sleeping in kernel, and cause pthread_cond_wait to return
>>> to userland, this is called spurious wakeup, and other events, I
>>> can not think of yet, but I believe they exist.
>> Does this mean that pthread_cond_signal can also return EINTR? This
>> isn't in pthread_cond_signal(3) either.
> No, it will return zero, returning EINTR is not allowed.
Adding some more context by adding the appropriate POSIX spec material...
If successful, the pthread_cond_broadcast() and
pthread_cond_signal() functions shall return zero; otherwise, an error
number shall be returned to indicate the error.
The pthread_cond_broadcast() and pthread_cond_signal() function may fail if:
The value cond does not refer to an initialized condition variable.
These functions shall not return an error code of [EINTR].
So yes, EINTR not being allowed is by design and this backs up what
davidxu@ is stating above. Our manpage just doesn't explicitly call
this requirement out, unlike a Linux manpage I dug up and the
>> Is this the case that all system calls should be assumed to be able to
>> return EINTR or only those that have EINTR in their man pages?
More information about the freebsd-hackers