<div dir="ltr">There's some other complications here as well. Threads by default get their own nurseries, so you have such a safe window even in threaded programs --- but if another thread allocates enough (and subject to RTS options, IIRC -n matters here?) it could fill its nursery, and the RTS notices your thread's nursery is mostly unused and let the other thread start allocating from your nursery and shrink your safe window.<div><br></div><div>(Also, it looks to me like 8.2's runtime changed some things; I thought there was an option explicitly specifying/controlling the separate-nurseries behavior, but I didn't see it in checking through the runtime options just now.)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 22, 2017 at 2:15 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Actually, I'd say that it can, but only if used incorrectly. Which is why it's reallyUnsafe.<div><br></div><div>The OP is correct in that a gc at the wrong time can lead to spurious positives. The key to this is that, if you force everything to be evaluated to WHNF (so you actually have the pointers) and then gc, you have some determinacy as to when the next gc will happen: force to WHNF first, gc, make sure any subsequent operations between that and your reallyUnsafePtrEquality either don't allocate or fit in the nursery --- and in this case, you can trust the result. So it requires a fair amount of care, but there is a window in which it is safe. </div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin <span dir="ltr"><<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It cannot give false positives. If it could, that would make it totally worthless.<br>
<br>
Sent from my iPhone<br>
<div class="m_7165376565518506758HOEnZb"><div class="m_7165376565518506758h5"><br>
> On Nov 22, 2017, at 12:22 PM, Michael Walker <<a href="mailto:mike@barrucadu.co.uk" target="_blank">mike@barrucadu.co.uk</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> Can reallyUnsafePtrEquality give false positives? I can see how it<br>
> can give false negatives (eg, compiler optimisations increasing or<br>
> decreasing sharing), but I'm not so sure if it can give false<br>
> positives.<br>
><br>
> I don't see how in a garbage collected language two live values could<br>
> compare reference equal. Unless the implementation is something like:<br>
><br>
> reallyUnsafePtrEquality a b = getptr a == getptr b<br>
><br>
> ...as that then means that if the GC moves things after `getptr a` is<br>
> evaluated but before `getptr b` is, then you could get a false<br>
> positive. But that doesn't seem like a sensible implementation to me,<br>
> because then reallyUnsafePtrEquality would surely be totally useless.<br>
><br>
> --<br>
> Michael Walker (<a href="http://www.barrucadu.co.uk" rel="noreferrer" target="_blank">http://www.barrucadu.co.uk</a>)<br>
> ______________________________<wbr>_________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_7165376565518506758gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div>