Background processes setting O_NONBLOCK on ttys

[Peter Jeremy]

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