[Haskell-cafe] Can reallyUnsafePtrEquality give false positives?

[Brandon Allbery]

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.

(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.)

On Wed, Nov 22, 2017 at 2:15 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> Actually, I'd say that it can, but only if used incorrectly. Which is why
> it's reallyUnsafe.
>
> 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.
>
> On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin <andrew.thaddeus at gmail.com>
> wrote:
>
>> It cannot give false positives. If it could, that would make it totally
>> worthless.
>>
>> Sent from my iPhone
>>
>> > On Nov 22, 2017, at 12:22 PM, Michael Walker <mike at barrucadu.co.uk>
>> wrote:
>> >
>> > Hello,
>> >
>> > Can reallyUnsafePtrEquality give false positives?  I can see how it
>> > can give false negatives (eg, compiler optimisations increasing or
>> > decreasing sharing), but I'm not so sure if it can give false
>> > positives.
>> >
>> > I don't see how in a garbage collected language two live values could
>> > compare reference equal.  Unless the implementation is something like:
>> >
>> > reallyUnsafePtrEquality a b = getptr a == getptr b
>> >
>> > ...as that then means that if the GC moves things after `getptr a` is
>> > evaluated but before `getptr b` is, then you could get a false
>> > positive.  But that doesn't seem like a sensible implementation to me,
>> > because then reallyUnsafePtrEquality would surely be totally useless.
>> >
>> > --
>> > Michael Walker (http://www.barrucadu.co.uk)
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171122/36411eb8/attachment.html>