Re: flock(2): locking against itself?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> "They're per-open"
> That's not bad for this level of description.

Agreed!

>> ...which is not actually difficult to understand since it's the same
>> as the seek pointer behavior; that is, seek pointers are per-open
>> too.
> and almost all the other transient attributes, that is distinct from
> stable attributes like owner, group, permissions, which are inode
> attributes.  In our current system I think just close on exec is a
> per fd (transient) attribute though if we follow linux (I think) and
> soon to be POSIX, and add close on fork, that would be another.

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.

I've also wished for a way to suppress SIGPIPE akin to MSG_NOSIGNAL to
send().  This is relevant here because it would be useful to have it as
a per-descriptor (or for my immediate use case even a per-open-file)
option, though it would also be nice to have it as a per-call option
(akin to Linux's writev2, though the Linux writev manpage I checked
doesn't have any such flag - it merely has room for it).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B