[Openmcl-devel] Issues with ccl:process-interrupt

[Gary Byers]

On Mon, 6 Jul 2009, David Findlay wrote:

> Hi,
>
> I've been successfully using CCL on Mac OS (both 32-bit PPC and 64-bit x86
> platforms) and Linux (64-bit x86) for some while.
>
> With the additional support for 32-bit x86 platforms provided by CCL 1.3, I
> have tried running my application on some 32-bit platforms, but without
> success. The problem seems related to ccl:process-interrupt. There seem to
> be two different issues: one on 32-bit x86 Linux platforms, and one on
> Windows platforms. In both cases, the issue can be demonstrated by typing
> the following form at the listener:
>
> (ccl:process-run-function "foo"

>  (lambda (p) (ccl:process-interrupt p #'print 'hi))
>  ccl:*current-process*)
>
> (That is, make a process to interrupt the listener and cause it to print
> HI.)
>
> 1. On the Linux platform, the return value from process-run-function is
> printed, and then Lisp simply exits with a Trace/BPT trap.

Please update from svn and rebuild the lisp; I believe that this was fixed a
few months ago.

>
> 2. On the Windows platform, the return value from process-run-function is
> printed, and then ... nothing. Just the Lisp reader prompt. Only when the
> *next* form is entered does Lisp condescend to execute the interrupting
> #'print and output the HI.

The listener process is generally in a blocking read() call (reading standard
input) at the point where you're trying to interrupt it.  On Unix systems, 
interrupting a system call has well-defined behavior (even if that behavior's
a bit funky: the system call returns an error indicator and the caller generally
has to retry at some point.)  On Windows ... well, there are some blocking
operations that can "wait in an alertable state" and some kinds of I/O
operations can be aborted, but it's a bit more ad hoc.

Note that:

? (process-run-function "Banzai!" (lambda (p) (sleep 10) (process-interrupt p (l
ambda () (break "Surprise!")))) *current-process*)
#<PROCESS Banzai!(4) [Reset] #x8A4EC5E>
? (sleep 100)
> Break: Surprise!
> While executing: #<Anonymous Function #x8A4FF6E>, in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Return from BREAK.
> Type :? for other options.
1 >

behaves as one would expect: the SLEEP is sleeping by "waiting in an alertable
state" in Windows parlance, and the background thread will interrupt the listener
about 10 seconds after the background thread starts.

If the listener was just READing (rather than SLEEPing), whether or not it can
be reliably interrupted seems to depend on the kind of I/O device it's reading
from; what Windows calls "Overlapped I/O" generally does involve this alertable
wait state, but only some kinds of streams use this mechanism (and only use
it for blocking operations.

There's allegedly a way of canceling a pending non-overlapped I/O operation
in Vista and CCL tries to detect whether or not this functionality is present
and to use it, but it seems that we're either not using it correctly or it
just doesn't do what I think it does.

Only certain types of I/O devices support the (more reliably
interruptible) "overlapped I/O"; I don't know of any way under Windows
to tell whether or not a particular file handle was created with the
option that requests this functionality, and I don't know of a way to
re-open an existing handle (such as the one attached to the process's
standard input) with the overlapped flag set.

There's certainly a lot that I don't know, but based on what I do know ...
well, if you can't say anything nice about an OS, it's better not to say
anything at all.

AFAIK, I/O on sockets is always "overlapped" and therefore interruptible;
I/O to/from a Windows console or a pipe device generally isn't.


>
> I haven't been able to find any reference to these behaviours on the
> clozure.com website. Are these known issues?

For some value of "known", yes.  I have the deja vu-like sense of having
written paragraphs much like those above a time or two before, but if so,
I don't know where I would have done so.

There might be some approach to working around all of this by trying to
avoid blocking I/O (or by avoiding operations which block indefinitely
in the REPL on Windows.) That's certainly ugly, but explaining and trying
to understand all of this - and/or finding other workarounds - aren't 
exactly attractive options, either.)

>
> Thanks
>
> David Findlay
>
>
> -- 
> Roke Manor Research Ltd, Romsey,
> Hampshire, SO51 0ZN, United Kingdom
>
> A Siemens company
> Registered in England & Wales at:
> Siemens plc, Faraday House, Sir William Siemens Square,
> Frimley, Camberley, GU16 8QD. Registered No: 267550
> ------------------------------------------------------------------------
> Visit our website at www.roke.co.uk
> ------------------------------------------------------------------------
> The information contained in this e-mail and any attachments is
> proprietary to Roke Manor Research Ltd and must not be passed to any
> third party without permission. This communication is for information
> only and shall not create or change any contractual relationship.
> ------------------------------------------------------------------------
>
> Please consider the environment before printing this email
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>