Date: Tue, 07 Sep 2010 17:46:19 +0000 From: David Xu <davidxu@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-threads@freebsd.org Subject: Re: sigwait() cancellation point Message-ID: <4C867A6B.8040408@freebsd.org> In-Reply-To: <20100907094249.GA2465@deviant.kiev.zoral.com.ua> References: <20100906220041.GA4729@stack.nl> <4C86787E.6070908@freebsd.org> <20100907094249.GA2465@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C867A6B.8040408>