kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call

[Jilles Tjoelker]

On Mon, Feb 04, 2013 at 05:45:40PM +1100, Bruce Evans wrote:
> On Sun, 3 Feb 2013, Eitan Adler wrote:
> > On 3 February 2013 16:00, Giorgos Keramidas <keramida at freebsd.org> wrote:
> >> The following reply was made to PR kern/175674; it has been noted by GNATS.
> >> > The best way to fix this is in kern_openat() in the kernel but this
> >> > might cause compatibility issues.

> >>  Not sure if there would be serious compatibility problems if
> >>  open() would automatically restart instead of returning EINTR.  It
> >>  definitely seems a rather intrusive change though.

> > I can not see major application breakage should open(3) be changed.

> > That said,  I am confused by jilles' comment:
> > http://pubs.opengroup.org/onlinepubs/000095399/functions/open.html
> > open(3) is permitted to return EINTR.

> Actually, open(3) is _required_ to return EINTR (if a signal occurs).

> This hasn't changed since the old (2001) POSIX draft that I quoted in a
> more detailed reply.  The wording is "shall fail...[with EINTR] if a
> signal was caught during open()".  Only a perverse implementation of
> weaselnix would justify not returning EINTR by not catching signals.

Many more functions have an [EINTR] error condition specified and
SA_RESTART is usually not mentioned.

This is because SA_RESTART is specified in the sigaction() page to
override the [EINTR] error unless explicitly specified otherwise (for
example, read(), write(), sleep(), select() and pselect()). There is a
change in POSIX.1-2008 for functions with timeouts.

-- 
Jilles Tjoelker