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