Am Mi., 23. März 2022 um 16:12 Uhr schrieb Nala Ginrut <xxxxxx@gmail.com>:

Crossposting this to the SRFI 226 mailing list.

> On Tue, Mar 22, 2022 at 12:22 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> SRFI 18/226 threads do report results so there's no missing feature.
>>
>
> I've checked SRFI-18, there's end-result. So yes.
> Here are my points on the issues listed in SRFI-226:
> The features other than threads in 18 should be dropped.
> For historical reasons, 18 had added extra features as the base of the threads, and some of the features are redundant in R7RS, say, with-exception-handler.

These are not completely irrelevant for SRFI 226 (or SRFI 18), for
example, because R[67]RS do not specify the initial exception handler
for threads nor give access to the current exception handler.

> We need to decide if we should make a modern threads API like futures in R7RS-large, or just borrow the SRFI-18 threads API.
> Or add them both.
> Here're what futures need:
> 1. managed thread pool

Wouldn't this be part of the low-level implementation underlying the
threads API of SRFI 18/226?

> 2. status (running, returned, etc) which is missing in SRFI-18

This could be added to SRFI 226 if it is clear what the "current
status" means. What are the semantics outside of synchronization
points?

> 3. result (already in SRFI-18)
> 4. thread-terminate! (I vote to keep thread-terminate! as the response to the issued question in SRFI-226).

I'm also inclined to leave it in. To avoid the corruption of internal
data structures, thread-terminate! won't immediately terminate a
thread (what that means isn't well-defined anyway, see my comment
about the status above), so there's no guarantee that it is
implemented through pthread_kill, say. Instead, all that can be said
is that a thread may be terminated at any point and that certain
synchronizing procedures like those locking a mutex or waiting for a
condition variable won't return if a termination request is pending.

>> It possibly makes sense to discuss a future API in committee B unless
>> F abandons threads altogether and replaces them with futures covering
>> the lower-level details. I'm not yet sure about the latter because
>> SRFI 18 is well-known and has seen plenty of implementations while a
>> future API will be something necessarily new.
>>
>
> I think SRFI-18 provides the most useful features, if any possible, we can make some advanced features based on it.

Thank you for your input and independent valuation.