Re: SIGWINCH updates the SCREEN's idea of window size

[<Joe...@t-...>]

Don Cohen wrote:

>I saw the warning (c. 2004?) and concluded that this was not a good
>way to deal with signals.
Still applies.

Yet I think CLISP would benefit, like CMUCL, from an API which would
allow to declare signal handlers written in Lisp.
The effort estimate may be short sighted,
but the most important piece of work is to note a signal was invoked
in the signal handler, then later -- at a safe point to do so -- invoke
the Lisp callback (not unlike ^C signals were tested synchronously
on some platforms, then the break loop invoked).
A major difference with CMUCL is that CLISP normally hangs in
 (READ *standard-input*), instead of polling a set of fd.

Of course with MT you have the additional burden on deciding upon
which thread to invoke the delayed signal handler.


>The code I see in stream.d suggests there can only be one screen
>window.  Is there a good reason for that?
It is hooked to the one special terminal stream.

>Does WINCH give you a way to find out which window has been resized?
No. UNIX signals are one bit only.
However somebody else may know whether the OS normally delivers
SIGWINCH for anything else than stdin/stdout/stderr.

E.g. if you implement the telnet protocol on a socket stream, I believe
you'll have to deal with WILL/WONT_XY messages yourself.
Likewise for ssh connections.
I've no idea how ext:make-xterm-io-stream (name?) behaves.

Regards,
 Jörg Höhle