Date: Thu, 13 Jan 2005 12:05:58 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: Background processes setting O_NONBLOCK on ttys Message-ID: <20050113110558.GA27286@stack.nl> In-Reply-To: <20050113074721.GC79646@cirb503493.alcatel.com.au> References: <200501120949.j0C9nQCZ000573@dungeon.home> <200501121354.j0CDscrR002027@dungeon.home> <20050113074721.GC79646@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 13, 2005 at 06:47:21PM +1100, Peter Jeremy wrote: > On Wed, 2005-Jan-12 23:54:38 +1000, Stephen McKay wrote: > >c) Make O_NONBLOCK be per file descriptor (like FD_CLOEXEC). Thus, > >descriptors produced from dup() (for example) would have their own O_NONBLOCK > >flag, just as two descriptors from separate open() calls have today. > It might be useful to see what one of the POSIX experts think about this. > FreeBSD, NetBSD, OpenBSD and Linux all explicitly state that dup(2) > copies O_NONBLOCK (though Solaris 10 doesn't). It is reasonably likely > that existing code relies on the documented behaviour and will therefore > break when you move O_NONBLOCK from the file to the file descriptor. 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. 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 :( -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050113110558.GA27286>