On Wed, Mar 16, 2011 at 6:54 PM, David Xu <davi...@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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
