Carl Howells wrote: > On Tue, Jul 19, 2011 at 11:14 PM, yi huang <yi.codepla...@gmail.com> wrote: > > 2011/7/20 Eugene Kirpichov <ekirpic...@gmail.com> > >> > >> reallyUnsafePointerEq#, and it really is as unsafe as it sounds :) > >> > > Why is it so unsafe? i can't find any documentation on it. > > I think always compare pointer first is a good optimization. > > False positives and false negatives are both possible, depending on GC > timing.
At the moment, as implemented in ghc, false positives are not possible, because GC only happens on allocation [*], and there is no allocation happening in that primitive operation. I don't think this is going to change without a total rewrite of ghc, since allowing GC (i.e., moving pointers) at arbitrary times would be a fundamental change to the STG execution model. Pretty much everything else imaginable can happen; in particular, if two variables a and b compared equal at one point, they may later become different pointers again. In the parallel RTS, if you're unlucky, this may even be a permanent effect. Best regards, Bertram [*] we'll have thread-local GC for the first generation soon, but a lot of effort went into ensuring consistentcy of pointers seen by other threads. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe