Re: bug or feature in userland thread library (O_NONBLOCK)

On Wednesday, 15th June 2005, Luigi Rizzo wrote:

>I think our userland thread library (libc_r) has some bugs in
>handling descriptors.  I can reproduce the behaviour on -current
>and 4.x, and I believe it applies to 5.x too.  

While you are fixing this one, can you also fix another one? :-)

The O_NONBLOCK hack causes problems when used on file descriptors that
refer to ttys.

In particular, when you run a program linked with libc_r in the background
without redirecting all of stdin, stdout and stderr, the tty is set to
non-blocking (since O_NONBLOCK applies to file table entries, not individual
file descriptors, and all such tty file descriptors are dup'd from the
invoking shell).

Many ordinary programs die when stdin, stdout or stderr become non-blocking
outside their control.  This includes, for example, "cat", "tail" and "nvi".

I have "solved" this problem on my system by making it impossible for
programs to set their controlling terminal to non-blocking when they are
in the background.  I haven't gotten around to sending my proposed changes
to -arch for review (ENOTIME), but I can't think of any valid reason why
a process should expect to be able to set O_NONBLOCK on its tty when it
is not in the foreground.

A solution that may be more pleasing to others is to make libc_r not set
O_NONBLOCK on ttys when it's in the background.  If you are already finding
weird special cases for descriptors 0, 1 and 2, perhaps you can see where
this additional change would fit in.

Then again, there is talk of just deleting libc_r.  In my view, this
could happen today.

Stephen.