Date: Thu, 09 Sep 2010 14:29:27 +0000 From: David Xu <davidxu@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-threads@freebsd.org Subject: Re: sigwait() cancellation point Message-ID: <4C88EF47.4010906@freebsd.org> In-Reply-To: <20100908175609.GA30144@stack.nl> References: <20100906220041.GA4729@stack.nl> <4C86787E.6070908@freebsd.org> <20100908175609.GA30144@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Jilles Tjoelker 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.) > >> A system call can not return EINTR is not flexible, I think why don't >> we fix it in libc and libthr, but let kernel returns EINTR? > >> I have worked out a patch: > >> http://people.freebsd.org/~davidxu/patch/sigwait.diff > > The idea and patch seem sensible. Some man page changes seem in order > though: sigwaitinfo.2 should mention this difference between sigwait() > and sigwaitinfo() more explicitly. > problem is I still want to know which OS does not return EINTR ? it seems I can not find one on net, so is it an accident of the specification group?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C88EF47.4010906>