Re: flock(2): locking against itself?

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Thu, 30 Mar 2023 08:22:45 -0400 (EDT)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> 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.