> Date: Thu, 30 Mar 2023 08:22:45 -0400 (EDT) > From: Mouse <mo...@rodents-montreal.org> > > I actually ran into a case where this distinction caused trouble. I > have a program that uses curses for output but wants to do non-blocking > input. So I set stdin nonblocking and threw fd 0 into the poll() loop. > > But, in normal use, stdin and stdout come from the same open on the > session's tty, so setting stdin nonblocking also sets stdout > nonblocking, which curses is not prepared to handle, leading to large > screen updates getting partially lost. > > I'm not sure whether I think it'd be better for O_NONBLOCK to apply to > the descriptor - if that could even be done; the way things are > currently designed, in a lot of cases it needs to get pushed all the > way to the underlying object, in my case the tty (which then is > responsible for making that state non-permanent). I may need to find > some other approach.
O_NONBLOCK should really be part of the _operation_, not the _object_. If we had separate read/write_nonblock syscalls, problems like this would go away. It's unlikely there are many uses of read or write that behave sensibly with and without O_NONBLOCK anyway.