Re: flock(2): locking against itself?

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

>> Here, we have software that's crippled by lacking support for
>> producing its output in a generalized fashion - so, rather than
>> fixing the limitation, we depend on a heavyweight OS feature to work
>> around it?  [...]
> Or we have a library that is specifically designed and implemented to
> talk to a tty and optimaise the output so that it outputs the minimum
> amount of data to that tty and now someone complains that it doesn't
> work on something that is not a tty?

Fair point.

I'm actually complaining that it doesn't work connected to something
that _is_ a tty...when the tty is nonblocking.  Wanting the refresh
guts to be separate is just one way to address that.

Initially, it seemed to me that, given the usual intent of
nonblocking, something like that was necessary to fix it without
calling in heavyweight OS support like ptys and additional processes -
or, for versions sufficiently recent that nonblocking is an open file
table entry thing instead of a backing-object thing, depending on the
output tty being reopenable.

While writing this mail, it occurs to me that a mode wherein everything
operates same as now, except that output, instead of being pushed to
the tty with fwrite() or write() or writev() or whatever, is just
passed to a callback.  That would address my use cases with a much less
intrusive change.

/~\ 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