[Haskell-cafe] What does unpacking an MVar really mean?

Leon Smith leon.p.smith at gmail.com
Tue Jul 31 07:22:51 CEST 2012

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.spam at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120731/4d1283ea/attachment.htm>

More information about the Haskell-Cafe mailing list