[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Matt Birkholz
Subject: [MIT-Scheme-devel] multi-threading fun: Ye ol' console-screen input handling.
Date: Sat, 28 Apr 2012 12:01:34 -0700

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

        (let ((mask (SET-INTERRUPT-ENABLES! interrupt-mask/gc-ok)))
          (cond ...
                 (SET-INTERRUPT-ENABLES! mask)
                 (let ((flag
                         (x-display-descriptor display)
                   (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

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. :-}

reply via email to

[Prev in Thread] Current Thread [Next in Thread]