[MIT-Scheme-devel] multi-threading fun: Ye ol' console-screen input handling.

[Matt Birkholz]

I was looking into why Edwin echoes ESC (the command key prefix) in an
xterm-screen but not in a console-screen, and I noticed that the
xterm-screen's input operations polled the same set of event sources
BUT took care to do so atomically using set-interrupt-enables! like
this:

        (let ((mask (SET-INTERRUPT-ENABLES! interrupt-mask/gc-ok)))
          (cond ...
                ((process-status-changes?)
                 (SET-INTERRUPT-ENABLES! mask)
                 event:process-status)
                (else
                 (let ((flag
                        (test-for-io-on-descriptor
                         (x-display-descriptor display)
                         block?
                         'READ)))
                   (SET-INTERRUPT-ENABLES! mask)
                   (case flag
                     ...)))))

The console-screen's input operations did not do this!  Perhaps it was
written when Scheme was single threaded?  It seems to me that the
atomicity is necessary.

If a process status changes between the poll (in process-status-
changes?)  and the block (in test-for-io-on-descriptor), the Edwin
thread will block even though a process status change is pending.  The
change will not be noticed until some subsequent event unblocks
test-for-io-on-descriptor.

Another potential problem was the call to channel-read.  That
procedure also uses test-for-io-on-descriptor but, when a process
status changes, calls the runtime's handle-subprocess-status-change
and then loops waiting for actual input.  Edwin continues to be
blocked and its handle-process-status-changes is not called.

The patch I just pushed employs set-interrupt-enables! and replaces
channel-read with %channel-read -- a version that returns #t when it
is unblocked by an interrupt or process status change.  The blocking
that stymied echoing of the ESC command key prefix is also avoided.

Now: ESC is echoed, function keys are recognized (within a 500msec
interval), and the console-screen should be a LOT more thread-safe.

If not, scream in my direction. :-}