On Wed, Mar 4, 2020 at 11:46 AM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:

A quick look gives me the feeling that this is very close to SRFI-18 (with some SRFI-21 things added) but using a different name (future-… instead of thread-…).  So I don’t see the point in going in that direction, rather than using SRFI-18 as a basis and extending it with new operations.  But then again these new operations are probably going to be more controversial than the established SRFI-18, so why not simply put up SRFI-18 for adoption, and then have a separate document with the extensions?

Primarily because I wanted an interface that was at par with various current functional languages, and in particular I wanted to add a couple of features I thought were very important nowadays: thread-local variables and soft interruptibility. 

In order to do that, I had to hide some other features like the "specific" field (it would be easy to put it back as a component of the SRFI-18 specific field, if anyone needs it).  I also hid hard interruptibility (which interoperates poorly with any sort of locks), provided a more straightforward mechanism that replaced the need for time objects, and hid mutexes and condition variables for future consideration.
Scheme would greatly benefit from having a basic set of threading primitives that can be built upon… “basic” but still clean and extensible… indeed SRFI-21 is an extension of SRFI-18 with priorities (which I would expect to be controversial due to the absence of priorities in some thread systems).

Again per FuturesCowan, a trivial no-op implementation of SRFI 21 on top of SRFI 18 can be made in about ten lines of code, if I correctly understand what SRFI-21 guarantees and does not guarantee.   So any implementation that provides SRFI-18 might as well provide SRFI-21, and FuturesCowan includes the SRFI-21-specific procedures for that reason.

If I'm wrong about SRFI-21, let me know.

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
With techies, I've generally found
If your arguments lose the first round
Make it rhyme, make it scan / Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie