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. :-}
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
