On Tue, Jan 6, 2009 at 8:51 PM, Philip Guenther <guent...@gmail.com> wrote:
> 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.
My opinion is that for vi this is more a corner case. I think it's
reasonable for vi to assume it has blocking fds to start, and for the
shell to enforce that. Same for any other app that doesn't anticipate
being toggled with another app on console. But gmake is actively
execing other jobs. It *knows* that other processes are running and
that they are likely writing to stdout, so it should handle this case.
Fixing every program that writes out data to use a loop is certainly
overkill, but I don't think fixing every program that uses fork+exec
to reset or deal with non-blocking shared descriptors is too much to
ask.
