Date: Thu, 13 Jan 2005 22:44:16 +1000 From: Stephen McKay <smckay@internode.on.net> To: Jilles Tjoelker <jilles@stack.nl> Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: Background processes setting O_NONBLOCK on ttys Message-ID: <200501131244.j0DCiGga008717@dungeon.home> In-Reply-To: <20050113110558.GA27286@stack.nl> from Jilles Tjoelker at "Thu, 13 Jan 2005 12:05:58 %2B0100" References: <200501120949.j0C9nQCZ000573@dungeon.home> <200501121354.j0CDscrR002027@dungeon.home> <20050113074721.GC79646@cirb503493.alcatel.com.au> <20050113110558.GA27286@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 13th January 2005, Jilles Tjoelker wrote: >POSIX states that the O_NONBLOCK flag is per open file description. File >descriptors created with dup(2), fork(2) or similar methods share the >same open file description, while new descriptors created with open(2) >do not. Can you quote chapter and verse on this? Or is it merely implied? A pointer to an online copy would be best. I found that "The Open Group Base Specifications Issue 6" at http://www.opengroup.org/onlinepubs/009695399/toc.htm is not clear on the matter. Also "The Single UNIX Specification, Version 2" at http://www.opengroup.org/onlinepubs/007908799/ is similarly unclear. >Consequently, a POSIX-compliant implementation of O_NONBLOCK does not >solve the problem, as all descriptors to the terminal refer to the same >open file description. O_NONBLOCK is indeed unusable for descriptions >shared with other unknowing processes :( If we must be POSIX compliant and if you accept that POSIX demands that dup'd file descriptors share a single O_NONBLOCK flag, then the logical end position is that the threads library must not routinely set stdin, stdout and stderr to non-blocking. Right? Personally, I have no qualms being non-POSIX compliant in a good cause. Wouldn't being non-POSIX on this issue be easier? Hmm. Should this be on -arch now? Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501131244.j0DCiGga008717>