> On Mar 4, 2020, at 6:23 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
>
>
> 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.

The thread specific field is useful to attach information that is specific for that thread.  One use is as a single cell of thread local storage.  This can easily be extended to multiple cells by storing in the specific field a list, vector or hash table with all the cells needed.  It allows other threads to access this form of “thread local storage” that is not possible with only a thread local dynamic environment.  You will also notice that SRFI 18 specifies that mutexes and condition variables have a specific field.  This makes it easy to extend these threading objects to implement higner level threading systems without having to wrap the objects in another type (this is mostly useful for threads because (current-thread) returns the SRFI 18 thread).

I don’t see anything related to soft interruptibility in FuturesCowan.  It would be simple to drop thread-terminate! if it is controversial.  It wasn’t controversial when SRFI 18 was discussed and many Schemes currently implement it.

FuturesCowan also drops mutexes and condition variables.  How will the threads coordinate their actions without this?  future-wait is too weak for many use cases.  Having threads without a means for coordination does not help much.  The time objects that were also dropped are particularly important for allowing timeouts on all operations that can cause the thread to wait, including mutex locking and thread joining, but also I/O.

>
> 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.

This part of the SRFI 21 spec is the issue:

“Let P(T) be the effective priority of thread T and let R(T) be the most recent time when one of the following events occurred for thread T, thus making it runnable: T was started by calling thread-start!, T called thread-yield!, T expired its quantum, or T was unblocked. Let the relation NL(T1,T2), "T1 no later than T2", be true if P(T1)<P(T2) or P(T1)=P(T2) and R(T1)>R(T2), and false otherwise. The system must schedule the execution of threads in such a way that whenever there is at least one runnable thread, 1) within a finite time at least one thread will be running, and 2) there is never a pair of runnable threads T1 and T2 for which NL(T1,T2) is true and T1 is not running and T2 is running.”

Specifically the last part.  It means that when a thread is currently running, the thread scheduler can’t prevent a runnable thread of higher priority from running (for more than the duration of a “tick”).  In other words the thread priorities can’t be ignored forever.

FuturesCowan specifies that “Prioritized futures are a feature of this SRFI that specific Scheme implementations may or may not provide.”

I find this surprising because such optional features are best put is a separate SRFI and implementations can either provide that feature (and SRFI) or not.  It allows testing for the feature with cond-expand.  To my knowledge, only Gambit implements SRFI 21, so priorities are probably a controversial feature among implementors.  I don’t think adopting priorities are a priority for standardization…

The (re)use of the term “future” in FuturesCowan is unfortunate because there is quite an extensive prior work in the Lisp/Scheme community on “futures” (the concept going back to Baker & Hewitt 1978 and certainly implemented by over a dozen implementations of Lisp/Scheme over the years).  The spec for (future proc arg…) conflicts with the established (future expr) form that forks a new thread and executes expr and the continuation in different threads, and returns a placeholder/promise representing the result of expr.  Of course, it is quite easy to implement (future expr) on top of SRFI 18 and promises, but an efficient implementation requires help from the compiler.  Indeed the initial motivation for creating the Gambit compiler was to explore the efficient implementation of futures (see https://www.semanticscholar.org/paper/An-efficient-and-general-implementation-of-futures-Feeley/1d0bfe48b65f8c4e0a0a2a31b00c4c509a234783).

Marc