Let me clarify a bit.
I am familiar with the source of Control.Concurrent.MVar, and I do see {-#
UNPACK #-}'ed MVars around, for example in GHC's IO manager. What I
should have asked is, what does an MVar# look like? This cannot be
inferred from Haskell source; though I suppose I could have tried to read
the Runtime source.
Now, one would hope that and (MVar# RealWorld footype) would
approximately correspond to a "footype * mvar;" variable in C. The
problem is this cannot _always_ be the case, because you can alias the
(MVar# RealWorld footype) by placing a single MVar into two unpacked
columns in two different data structures. So you would need to be able
to still sometimes represent an MVar# by a footype ** mvar at runtime,
even though one would hope that it would be represented by a "footype *
mvar" in one particular data structure.
On Tue, Jul 31, 2012 at 1:04 AM, Ryan Ingram <ryani.s...@gmail.com> wrote:
>
> Because of this, boxed MVars can be garbage collected without necessarily
> garbage-collecting the MVar# it holds, if a live reference to that MVar#
> still exists elsewhere.
>
I was asking the dual question: if the MVar# exists in some data
structure, can that data structure still be garbage collected when there
is a reference to the MVar#, but not the data structure it is contained
within.
Best,
Leon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
