Re: flock(2): locking against itself?

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

>> (1) [libcurses] does not get along with input and/or output being
>> set non-blocking.

> Bug.

Well...see below.

> While, in principle, when you're using curses it owns both the input
> and the output, in practice because curses input can't cope with
> select loops it's common for curses applications to use curses only
> for output

Mine is an example.

> and do other things with the input, so it's reasonable for the input
> to be nonblocking and this can make the output nonblocking as well.

Exactly my problem.

> However, I'd expect that getting a second open of the same tty for
> the output would work around this.  (dup isn't enough, but a new open
> should work, because non-blocking I/O is a file-handle-level mode,
> not a tty driver mode.)

This is OS-version-dependent.  (Well, assuming that you actually know
what you're talking about, which seems like a safe bet to me.)  On the
versions I know, it is state in the backing object, in this case
meaning the tty driver.

But also, if we've got differences that fundamental here, don't count
on _your_ libcurses to (mis)behave the same way _mine_ does.

> Since it apparently doesn't my guess is that there are places in the
> curses code that don't clearly distinguish input and output and this
> causes it to get tangled in its shoelaces when they aren't the same
> object.

There is that.  For example, it fiddles the tty modes using the input,
but it gets the tty size from the output.

> Unfortunately fixing all of this is not trivial, so nobody's likely
> to take it up anytime soon.

I am likely to take it up in the sense of extracting from curses enough
to build an output-only variant that has no OS dependencies, calling
back to its calling program for everything that the current libcurses
uses OS-dependent anything for.  (Getting the tty size is an example.
I'm not sure how I feel about looking up terminal outpout sequences,
the stuff -ltermcap handles.)

> My recommendation for this would be to restructure the whole thing to
> use its own handle structure internally that has an ops table so at
> least the mess is contained in one place.  But this is a large
> undertaking too.

> Then of course you also need a nonstandard replacement newterm() that
> provides the extra ops needed.

Oh, yes, whatever I end up with will definitely be nonstandard.  That's
part of why I was asking if there'd be any interest in the result.

>> (4) There's no way, without going under stdio's hood, to create a
>> stdio stream that operates like a funopen()ed stream but allows the
>> caller to arrange for fileno() to return something useful.
> That probably isn't the right direction to go in, I think.

I agree and I disagree.

I agree it is not a right direction to go for fixing curses.

But I do think it is something that something like funopen should
support, in that I think it should be possible to build a stdio stream
"manually" (using something funopenish) that is completely
indistinguishable from a stream opened with, say, fopen.  That means,
in particular, that fileno() has to "work".

>> (b) Does anyone know of any work done towards pulling the screen
>> updater out of curses, so it can be used without all the baggage
>> tied to the OS that libcurses imposes?

>> (c) If not, would there be any interest in such a thing?

> As you probably remember I've argued at length in the past that
> memory-mapped screens should have a memory-mapped screen interface at
> the device level.

To an extent they already do, do they not, via wscons?

> (In which case that screen updater is only needed as a driver for
> serial-attached terminals.)

Or ssh logins, or legacy code, at least the former of which is not
optional for my use cases.

> Anyway, my guess is that pulling the screen updater out is roughly
> the same as what I suggested above about using its own handle
> structure internally, if you want something that works more or less
> like the current curses (you feed it text, it outputs other text).

Mostly, yes, though I'm not sure what I'd come up with would be
suitable for replacing the guts of (the output side of) curses with.

> If opening a second fd for output doesn't work

Not for me, it doesn't, because nonblocking is in the tty layer, not
the open file table entry.  (It also assumes the output is connected to
something that's reopenable.  While that's true in my use cases, it's
an assumption I'd rather not make if I can avoid it.  I'd prefer
something like curses that can "output" to callbacks, a la funopen, not
necessarily to a file descriptor.)

> I guess the other question is: for what you're doing, do you really
> need the full screen updater?  Unless it's intended to talk over a
> slow serial line (like, less than 19200 bps) a much simpler
> line-at-a-time updater will serve perfectly well.  I imagine there
> are some extant implementations already, and if not, writing one will
> probably be less work than grinding the curses we have.

Hm.

I'll have to think about that.  At the very least, that's another
assumption I'd rather avoid making, the assumption of high bandwidth
between the program and the output screen.

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