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 <keram...@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 _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
