sigwait() cancellation point
David Xu
davidxu at freebsd.org
Tue Sep 7 09:46:20 UTC 2010
Kostik Belousov wrote:
> On Tue, Sep 07, 2010 at 05:38:06PM +0000, David Xu wrote:
>> Jilles Tjoelker wrote:
>>> Our sigwait() implementation may not be POSIX-compliant as it returns
>>> EINTR when it is interrupted by a caught signal. (Unfortunately I can
>>> only find this in SUSv4 in the Rationale, B.2.3 Error Numbers,
>>> Disallowing Return of the [EINTR] Error Code; the sigwait() page in XSH
>>> does not list an [EINTR] error condition, but does not prohibit one
>>> either like pthread_mutex_lock() and various others do.)
>>>
>>> However, libthr's wrapper for sigwait() relies on EINTR. To keep
>>> the possibility of changing this to be what POSIX intends, it would be
>>> nice to remove this dependency.
>>>
>>> One way is to include SIGCANCEL in the set of waited signals, but this
>>> requires two additional syscalls to mask/unmask SIGCANCEL.
>>>
>>> Another way is to use sigwaitinfo() in the wrapper, which is permitted
>>> to return [EINTR]. If [EINTR] is removed from the kernel sigwait(),
>>> looping on [EINTR] can then be implemented in the wrapper.
>>>
>>> Calling pthread_exit from the SIGCANCEL handler is not possible as this
>>> leaves the program in doubt about any signal consumed by sigwait().
>>>
>> I have worked out a patch:
>>
>> http://people.freebsd.org/~davidxu/patch/sigwait.diff
> Isn't __sys_sigwait() supposed to return -1 and set errno ?
No, it returns error code, and zero means success.
More information about the freebsd-threads
mailing list