Am Di., 11. Okt. 2022 um 16:53 Uhr schrieb Marc Feeley <[email protected]>: > > 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
