[Openmcl-devel] interrupt signal on windows

[Gary Byers]

On Sun, 29 Nov 2009, harshrc wrote:

> Hello,
>
> In CCL running on Linux(x86), if one continually presses Ctrl-C
> (keyboard interrupt), then
> you see ? , 1> , 2> , 3> and so on nested debug levels, (quit) will exit
> completely.
>
> In CCL running on Windows, the above consistent behavior is not
> obtained, instead
> you see ? , ? , 1> , 2> , 3> , 2> , 3> ..., and (quit), followed by
> another (quit) will
> exit completely.
>
> Is this a bug in CCL Windows implementation?

It's at the very least clear evidence that Windows isn't Unix.

You're describing what happens when the listener thread receives an
interrupt while it's waiting for input.  On a Unix system, that's a
case of a blocking system call ('read') being interrupted by the
reciept of a handled signal; when CCL establishes handlers for the
signal(s) in question, it specifies that it wants the interrupted
system call to return a special pseudo-error indicator that says that
the system call was interrupted.  Another alternative would be to have
the OS automatically retry the system call; that's easier to deal with
at some level (the caller doesn't have to remember to check for the
"interrupted" return value and retry itself), but the behavior that
CCL specifies lets us respond to interrupts as soon as possible: the
system call returns to lisp code as soon as it's interrupted by a
signal and lisp notices and processes the pending interrupt.

Windows has no similar general concept of signals, and therefor has
no real concept of "interrupted system calls".  Vista introduced
some new mechanisms to cancel pending I/O operations in other threads
(which is sort of what we're looking for ...), but it's not clear that
those mechanisms work in all cases; specifically, I don't believe that
a blocking read from the console input device can be cancelled.  Once
the blocking read from the console starts, it'll only return if the
user types 0 or more characters followed by the return key.  (This
is true if the console device is processing input in "line" mode, as
it is by default.)

Windows -does- have a mechanism for waiting for certain kinds of state
changes in an "alertable" (aka "interruptible") way; unfortunately,
waiting on the console input device can only detect the presence of
raw input events (e.g., it isn't possible to do an alertable wait 
for the input device to have a line of "cooked" input.)  CCL 1.4 actually
handles this mess a bit better than 1.3 did; it tries to defer the blocking
read until it's reasonably sure that there are pending keyboard events; that
may make it more likely that (for instance) a ^C at the beginning of a line
will be handled immediately, but if there are pending keyboard events we
pretty much have to do the blocking read to process them (and can't process
the interrupt until that blocking read completes.)

(In at least some cases in your example, the keyboard event that generated
the ^C is still in the event stream on the next attempt to read from the
console input device; we see a keyboard event and do a blocking read.  It
may be possible to special-case any events that generate ^C, but that would
at best make things incrementally better.)

Since most of the problems here stem from the need to do a blocking read
as soon as key events are generated (since the blocking read is responsible
for handling backspace and other editing operations), a more general solution
would be to do all of that event->characters stuff ourselves.  I don't have
a good sense of how easy or hard that'd be.

>
> I maintain ACL2 Sedan, and I have noticed that the first interrupt(to
> interrupt a long
> proof or execution) works correctly, but the second interrupt (i.e
> rerunning the above
> long running computation and re-interrupting) does not work as expected
> and in fact
> ACL2(built with CCL) becomes a runaway process which I need to kill
> explicitly using
> Windows Task Manager. And I suspect that perhaps the above Ctrl-C
> behavior of CCL on
> Windows is whats causing this problem in ACL2 Sedan. ACL2 Sedan running
> on Linux with
> CCL works perfectly, i.e. this is a windows-specific issue.
>
> Any feedback would be helpful.
>
> thanks
> /harsh
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>