Am Sa., 29. Okt. 2022 um 15:49 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:

> > One alternative to thread-local storage is to use subtyping of the thread type.  In Gambit this is done with the define-type-of-thread form.  Here’s a quick example:
> >
> >   $ gsi
> >   Gambit v4.9.4
> >
> >   > (define-type-of-thread mythread (counter))  ;; add a counter field to threads
> >   > (define t (make-mythread 0))  ;; make a thread with counter = 0
> >   > (define (run) (let loop () (mythread-counter-set! (current-thread) (+ 1 (mythread-counter (current-thread)))) (loop)))
> >   > (thread-start! (thread-init! t run))
> >   #<thread #2>
> >   > (mythread-counter t)
> >   82460212
>
> I like the idea of inheriting from the thread type.  This generalizes
> the thread-specific field nicely.  I would retain thread locals, as
> well, because they are a helpful API as well: The "parent" thread
> determines the shape of the thread object for the "child" thread, so
> the "child" thread cannot dynamically add information to itself.

So, let us assume that the system that provides SRFI 226 also has
record types with inheritance (e.g. through SRFI 237).  Then it makes
sense that SRFI 226 exports a record name `thread' so that the
system's primitives can be used to extend the record and we don't need
a custom `define-type-of-thread`. E.g.:

(define-record-type mythread
  (parent thread)
  (field counter))
(define t (make-mythread THUNK 0))
...

If `thread' becomes a record name, I have to drop the convenience
syntax named `thread' in the SRFI, but this makes sense when there is
more than `make-thread` but also "derived" versions with more
arguments.

I see that your code has `thread-init!`, which isn't in SRFI 18. Is
all you can do with it postponing linking a thunk to run to the
thread?

M.