Date: Mon, 4 Feb 2013 17:45:40 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Eitan Adler <lists@eitanadler.com> Cc: freebsd-bugs@FreeBSD.org, Giorgos Keramidas <keramida@FreeBSD.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call Message-ID: <20130204173830.K1078@besplex.bde.org> In-Reply-To: <CAF6rxgmmftGBtMm4fOoExLgRz3RDd=omEP4zkW4wtLuq=T-Q6w@mail.gmail.com> References: <201302032100.r13L01PG044439@freefall.freebsd.org> <CAF6rxgmmftGBtMm4fOoExLgRz3RDd=omEP4zkW4wtLuq=T-Q6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Feb 2013, Eitan Adler wrote: > On 3 February 2013 16:00, Giorgos Keramidas <keramida@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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130204173830.K1078>