Is pthread_cond_signal(3) man page correct?

[Garrett Cooper]

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...

RETURN VALUE

    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.

ERRORS

    The pthread_cond_broadcast() and pthread_cond_signal() function may fail if:

    [EINVAL]
        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
OpenGroup manpage.

>> 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?

Thanks,
-Garrett