[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flow of control issues

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

  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?").)