[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: flow of control issues
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Tom> It's silent about asynchronous interrupts which, while not standard
> Tom> Scheme, are likely to be an important feature of most
> Tom> implementations. In an interactive application especially, absense of
> Tom> support for asynchronous interruption in "built-in" procedures can
> Tom> spoil an application's usability.
> Unfortunately, the interfaces to the asynchronous facilities vary
> greatly between platforms. I've found that polling is rarely enough.
> (MzScheme actually provides some functionality to interface with
> asynchronous facilities. It's a good start, but needs work to be made
> more Scheme-implementation-agnostic.)
> While this is an issue that's clearly worth addressing, it's not clear
> to me that it needs to be done in this SRFI.
It seems like your choices are:
~ declare that asynchronous interruption of C functions is expressly
forbidden: there may not be an asynchronous non-local exit and
there may not be asynchronous execution of arbitrary Scheme code.
That's a pretty unfortunate restriction to build into the
foundational SRFI of the portable FFI space. Either the FFI will
not be suitable for long-running functions or people will use it to
write less-than-generally-useful bindings for long-running
Nevertheless, let's call this the "base-level proposal" because
I think it is the one you intend and is certainly something that
any implementation should be able to provide.
~ declare that asynchronous interruption is unconstrained: non-local
exits or arbitrary execution of Scheme code can happen at any time.
This approach is just going to multiply the GC-safety and
unwind-protection issues of the FFI.
~ provide fully-general hooks into the async facility
I agree that this is inevitably too implementation-specific to get
right at the start.
The difference between this and the "base level proposal" is utterly
trivial. An implementation is free to make polling a noop.
Nevertheless, polling makes it possible to write generally useful
bindings for long-running functions.
(In this particular thread, I'm trying to remain agnostic on the issue
of non-local exits vs. error codes, but I will mention that polling is
easy to understand and use if it can not cause a non-local exit but
rather simply returns a boolean ("interrupt pending?").)