Java version of structured concurrency John Cowan (10 Oct 2022 16:20 UTC)
Re: Java version of structured concurrency Marc Nieper-Wißkirchen (11 Oct 2022 13:00 UTC)
Re: Java version of structured concurrency Marc Feeley (11 Oct 2022 14:53 UTC)
Re: Java version of structured concurrency Marc Nieper-Wißkirchen (11 Oct 2022 15:52 UTC)

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.