> So you don't think it's possible to create a Scheme level portable
> across implementations API?  I would not be surprised.

I don't know. Unix vs Windows is going to be problematic. Java threads
vs CLR threads vs OS threads is going to be problematic. Different GC
strategies and continuation implementations may be as well. This is just
about the most perilous topic anyone could possibly write a SRFI on...

> So ANSI terminal fundamentals, wherever they get put, are could have
> a highest level API that does whatever unspecified magic is required
> to both set up the handler and get events from it?

I don't think any terminal SRFIs should ever install any signal
handlers, either automatically or manually.

They should just provide a notify procedure that the user can call from
his own signal handler. That procedure doesn't even need to take any
arguments; it's just a wakeup call.

If a Scheme implementation has something like (add-signal-handler
<proc>) then the terminal notify proc could be added directly for simple
cases where you don't need to do anything else on SIGWINCH. No need to
write a wrapper lambda. Perhaps the notify proc can ignore its arguments
so it fits anywhere a hook can be installed.

> Or you could call ioctl frequently to see if the size has changed....
It's not that simple. Most of a terminal program's time is spent waiting
for a keystroke; they commonly stay dormant for hours. If the window is
resized during this time, it's confusing if the program waits until a
keystroke to call ioctl() and update its display. The point of SIGWINCH
is probably to interrupt this read() or poll() call so the program is
woken up to resize its display immediately. We should definitely enable
this user-friendly behavior in Scheme.