Re: Java version of structured concurrency
Marc Feeley 11 Oct 2022 14:53 UTC
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.
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.
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! .
Marc
> On Oct 11, 2022, at 9:00 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> Thank you for the link. I am thinking about this.
>
> What I think we probably need is a kind of "non-detached thread" that
> is garbage-collected when there are no more references to its thread
> object. (It may also be called a weak thread.) SRFI 18/226 threads are
> all detached in some sense.