[Haskell] garbage collection of Concurrent Haskell threads?

[Simon Peyton-Jones]

GHC already garbage-collects threads that are blocked on an MVar that is otherwise inaccessible (and hence cannot be updated).  More precisely, GHC sends the thread an asynchronous exception (ThreadBlocked or something), so that it has a chance to clean up.

So perhaps the GC you want is already implemented?

Simon

From: haskell-bounces at haskell.org [mailto:haskell-bounces at haskell.org] On Behalf Of Conal Elliott
Sent: 24 December 2007 00:15
To: haskell at haskell.org
Subject: [Haskell] garbage collection of Concurrent Haskell threads?

The classic paper "The Incremental Garbage Collection of Processes" (http://citeseer.ist.psu.edu/baker77incremental.html) describes "futures" and how particularly garbage collecting them when their pending result is no longer referenced.  I've been playing with an implementation of futures in Concurrent Haskell ( http://haskell.org/haskellwiki/Reactive), using MVars, and I'm stumped about how to GC non-winning threads in a race between futures ("parallel or").  I'm having winner kill loser, which seems to work fine, though is potentially dangerous w.r.t locked resources.  Still, the elegance of a GC-based solution appeals to me.  Has anyone explored process GC ideas for Concurrent Haskell (or STM)?

Futures are implemented using Concurrent Haskell's MVars.  I first tried using STM and TVars, simply using orElse to implement mappend for futures.  However, I didn't see how to avoid nesting "atomically", which yielded a run-time error.  If anyone has ideas about using STM & TVars for futures, I'd love to hear.

Thanks,  - Conal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell/attachments/20071224/aaa4a0a4/attachment-0001.htm