Date: Thu, 13 Jan 2005 18:47:21 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Stephen McKay <smckay@internode.on.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Background processes setting O_NONBLOCK on ttys Message-ID: <20050113074721.GC79646@cirb503493.alcatel.com.au> In-Reply-To: <200501121354.j0CDscrR002027@dungeon.home> References: <200501120949.j0C9nQCZ000573@dungeon.home> <200501121354.j0CDscrR002027@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2005-Jan-12 23:54:38 +1000, Stephen McKay wrote: >a) Rewrite file descriptor handling in libc_r so it does not set O_NONBLOCK >on tty file descriptors unless it is in the foreground. I don't know how >hard this would be, or whether it even applies to -current with its profusion >of threading libraries. I'll leave this to those who believe in threading. In 4.x, threads are totally userland and rely on non-blocking I/O. If background tty file descriptors block on I/O, the entire process will block, not just the thread performing I/O. This is a major POLA violation. In 5.x and later, both kernel and userland threads exist. >b) Add new non-blocking read() and write() call variants and use them in >the threading library instead of setting O_NONBLOCK. See aio_read(2), aio_write(2). >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. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050113074721.GC79646>