STM and garbage collector

If a thread is blocking indefinitely in an STM transaction (reading from a queue to which nobody else has a reference and thus can not write into), is the runtime smart enough to GC the thread? Or do I have to kill the thread manually?

In this case, the GC will indeed find that no one has a reference to the
thread. However, instead of garbage collecting the thread, the
BlockedIndefinitely exception is thrown to it. So, it resumes execution of
the thread with that exception.
This also applies to threads blocked on MVars.
-Michael
On Sat, Oct 17, 2015 at 9:11 AM, Tomas Carnecky
If a thread is blocking indefinitely in an STM transaction (reading from a queue to which nobody else has a reference and thus can not write into), is the runtime smart enough to GC the thread? Or do I have to kill the thread manually?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Who throws the exception? Documentation of `throwTo` sais that the calling
thread is blocked until the exception is delivered. If the target thread
has async exceptions masked then the exception is never delivered.
Does that also mean a blocked thread which has async exceptions masked is,
essentially, a resource leak?
On Sun, Oct 18, 2015 at 5:23 AM Michael Sloan
In this case, the GC will indeed find that no one has a reference to the thread. However, instead of garbage collecting the thread, the BlockedIndefinitely exception is thrown to it. So, it resumes execution of the thread with that exception.
This also applies to threads blocked on MVars.
-Michael
On Sat, Oct 17, 2015 at 9:11 AM, Tomas Carnecky
wrote: If a thread is blocking indefinitely in an STM transaction (reading from a queue to which nobody else has a reference and thus can not write into), is the runtime smart enough to GC the thread? Or do I have to kill the thread manually?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 10/18/2015 12:45 PM, Tomas Carnecky wrote:
Who throws the exception?
The RTS.
Documentation of `throwTo` sais that the calling thread is blocked until the exception is delivered. If the target thread has async exceptions masked then the exception is never delivered.
First, to attempt to cause that block, you'd have to use uninterruptibleMask, because the ordinary mask still lets the exceptions through when the thread is blocked. Second, in the case of BlockedIndefinitelyOnSTM and similar conditions, the RTS doesn't go through throwTo, but raises the exception directly, so even uninterruptibleMask won't hold it. See resurrectThreads in rts/Schedule.c.
Does that also mean a blocked thread which has async exceptions masked is, essentially, a resource leak?
On Sun, Oct 18, 2015 at 5:23 AM Michael Sloan
mailto:mgsloan@gmail.com> wrote: In this case, the GC will indeed find that no one has a reference to the thread. However, instead of garbage collecting the thread, the BlockedIndefinitely exception is thrown to it. So, it resumes execution of the thread with that exception.
This also applies to threads blocked on MVars.
-Michael
On Sat, Oct 17, 2015 at 9:11 AM, Tomas Carnecky
mailto:tomas.carnecky@gmail.com> wrote: If a thread is blocking indefinitely in an STM transaction (reading from a queue to which nobody else has a reference and thus can not write into), is the runtime smart enough to GC the thread? Or do I have to kill the thread manually?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (3)
-
Michael Sloan
-
Roman Cheplyaka
-
Tomas Carnecky