This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> 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
functions.
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.
~ polling
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?").)
-t