On Tue, Jan 6, 2009 at 5:07 PM, Ted Unangst <[email protected]> wrote:
...
> Let me qualify that. The reason for the maybe is that there can be
> many reasons for a program to set stdout to non-blocking. It may not
> always be the result of pthread fiddling. So gmake is still wrong.
> If its behavior depends on whether a fd is set nonblocking in a child,
> that's a problem. Just a problem that occurs less frequently without
> threads it seems.
Some of us wish that the non-blocking flag was an fd flag (like
FD_CLOEXEC) instead of a file table flag like it really is**; this
would have never been an issue then.
As for this being a bug in gmake, well, the same bug exists in *lots*
of programs. I used to hit it all the time with the system 'vi' when
debugging a threaded program that crashed, leaving the session's
std{in,out,err} as non-blocking. That mostly went away when the
system ksh started resetting the terminal to blocking when the
foreground process exited, but you can still hit it by running 'vi'
from inside a threaded program (with system()), then stopping and
starting the program and vi with ^Z and fg:
Error: input: Resource temporarily unavailable
Notice that resetting the state at startup isn't enough. Since the
state could be changed by another process at any moment, you actually
have to replace each should-be-blocking call with "try it, then poll()
and loop if EAGAIN" logic...which probably isn't correct for a
terminal device in non-canonical mode. Altering almost every program
on the system to do that seems like the Wrong Thing to me.
Philip Guenther
** Yes, yes, there would have had to been some way to specify
non-blocking open(). If we lived in that universe, the details would
have been worked out already.
