sigwait() cancellation point

[Jilles Tjoelker]

On Thu, Sep 09, 2010 at 02:29:27PM +0000, David Xu wrote:
> 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?

Recent versions of glibc do this. They implement
sigwait/sigwaitinfo/sigtimedwait based on a single extended sigtimedwait
system call; sigwait differs from the others by retrying when it gets
EINTR. This is not documented very well in man pages (for example, man
sigwait might get you an ancient LinuxThreads man page).

One reference:
http://lkml.indiana.edu/hypermail/linux/kernel/0508.0/0181.html

Google also provides various examples of applications that treated any
sigwait() error as fatal and needed to be changed to work reliably on
systems where sigwait() may return EINTR (not just FreeBSD).

-- 
Jilles Tjoelker