Let me clarify a bit.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><div class="gmail_quote">On Tue, Jul 31, 2012 at 1:04 AM, Ryan Ingram <span dir="ltr"><<a href="mailto:ryani.spam@gmail.com" target="_blank">ryani.spam@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Best,</div><div>Leon</div></div></div>