Am Di., 11. Okt. 2022 um 16:53 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:
>
> I view threads as an imperative construct.  As long as a thread is active it should be kept alive (not garbage-collected) if it can execute some action that is observable from other threads (a mutation, some I/O, unlocking a mutex, etc).  A thread should only be garbage-collected if the garbage-collector can prove (possibly with the help of a code analysis by the compiler) that this is not possible.

For a usual thread, this is true (and would remain valid). A weak
thread would be terminated when it is garbage collected. This can be
useful for threads whose purpose is to calculate and deliver a result
but where there is no receiver waiting for a result anymore. I find it
hard to imagine that the general case can be analyzed by a compiler.

> Can you explain a situation where “weak threads” would be useful and similar behavior could not be obtained with the usual “strong threads”?  I would think that the SRFI 18 thread-terminate! combined with ephemerons (or wills) would achieve the same thing.

John has been asking about a construct that manages the lifetime of
threads started within that construct. Now if this construct is
running in a thread that is itself terminated, the inferior threads
(following the rationale of the Java documentation he shared) should
also be (eventually) terminated. If this is to work without weak
threads, thread-terminate! would have to communicate with this
lifetime-management construct. I have been thinking that this latter
construct should be expressible in the primitives we already have.

> Gambit extends SRFI 18 with a useful construct for inter-thread communication: the thread-interrupt! procedure.  It allows interrupting a thread at a safe point to execute arbitrary code (wrapped in a thunk).  For example:
>
> (define t
>   (thread-start!
>    (make-thread
>     (lambda ()
>       (with-output-to-file
>           "foo"
>         (lambda ()
>           (let loop ()
>             (loop))))))))
>
> (thread-sleep! 1)
>
> (pp (thread-interrupt! t current-output-port)) ;; ask t for some info
>
> ;; prints: #<output-port #2 "/Users/feeley/foo”>
>
> Because Gambit’s thread-terminate! is implemented using thread-interrupt!, the victim thread will not be left in an inconsistent state when it is terminated with thread-terminate! .

What happens if the thunk does not return?

In what sense does it help with the problem above?

Thanks,

Marc