[Haskell] garbage collection of Concurrent Haskell threads?

[Conal Elliott]

Thanks, Simon.  If I understand the mechanism you're describing, it discards
readers of an empty MVar when there are no other references to the MVar
*because* the MVar can never get written.  And if there are other readers
but no writers, then I'm guessing GC wouldn't know that, and none of the
readers get discarded.  Is that so?

I think Baker & Hewitt's trick was analogous to discarding writers of an
already full MVar when there are readers (readMVar) but no takers
(takeMVar).  (Though not quite, since readMVar is implemented via takeMVar &
putMVar.)  I guess that effectively means IVars instead of MVars.

In either direction (blocked reader or blocked writer), the interface of
MVars (or IVars) would seem to prevent an accurate analysis, since GC
wouldn't know whether a Var reference was for reading or writing.  Right?  A
simple solution might be to hide the Var itself and instead expose reader
and writer halves.  If there's an analysis problem at all, does that
solution make sense?

Cheers,  - Conal

On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

>  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/7282134e/attachment.htm