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.
I understand.
It allows other threads to access this form of “thread local storage”
I think that is a bad point, actually.
that is not possible with only a thread local dynamic environment.
FuturesCowan does not put the thread-locals in the dynamic environment: it has separate ref and set! procedures to access them, Java style. Supplementary macros would probably be good here as well.
I don’t see anything related to soft interruptibility in FuturesCowan. ''
See the procedures future-abandon! and future-abandoned?.
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?
It hides them so that threads can be standardized even though thread coordination is still under consideration. Specifically, I am going to propose go-channels as the standard coordination interface, using conditions and mutexes under the table. I don't yet have a proposal, but I want to be able to standardize threads first.
This part of the SRFI 21 spec is the issue:
Thanks for pointing me to the relevant place. I have removed the SRFI-21-analogue procedures from FuturesCowan, and I agree that there is little point in trying to standardize SRFI 21 or anything like it.
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.
I have renamed the procedure to `make-future` and added the macro `future`, noting that it is equivalent to (make-future (lambda () expr)) but may be optimized by a compiler.
Racket already uses the term "future" for what I call parallel promises, which execute in parallel as far as the implementation can support it.
Another feature provided by FuturesCowan is that promises are treated as futures, as much as is possible; a promise is what a future would be if there is only one thread. I should probably add a degenerate implementation of futures on top of promises.