On Wed, Aug 20, 2014 at 3:07 PM, <p.k.f.holzensp...@utwente.nl> wrote:
> On Wed, Aug 20, 2014 at 1:47 PM, <p.k.f.holzensp...@utwente.nl> wrote: > >> >> <thread_id_bits:8> <unique_id_bits:56-X> <tag_bits:X> >> > >> > Is the thread id deterministic between runs? If not, please do not > use this layout. I remember vaguely Unique being relevant to ghc not > having deterministic builds, my most wanted ghc feature: > > https://ghc.haskell.org/trac/ghc/ticket/4012 > > > I think this depends on the policy GHC *will* have (there is not > parallel build atm) wrt. the forking of threads. An actual > Control.Concurrent.ThreadId might be as large as 64 bits, so, of course, we > won't be using that, but rather the sequence number in which the > UniqueSupply was "split off" for a new thread. In other words, if the > decision to fork threads is deterministic, so are the Uniques with this > layout. > > Mind you, I imagine a parallel GHC would still have at most one thread > working on a single module. I don't know too much about what makes it into > the interface file of a module (I can't imagine the exact Uniques end up > there, because they would overlap with other modules - with per-module > compilation - and conflict that way). > > Can you comment on how (the layout of) Uniques relate to #4012 in a > little more detail? It seems that if the Uniques that somehow end up in the > interface files could simply be stripped of the thread id, in which case, > the problem reduces to the current one. > > I frankly don't know. I just think it's better to keep ThreadId out of data that can bleed into symbols and what not. As you can see, the thread id is just a counter, and as forkIO in a threaded runtime will be racy between threads, they aren't deterministic. http://stackoverflow.com/questions/24995262/how-can-i-build-a-threadid-given-that-i-know-the-actual-number Alexander
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
