> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    > 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