Unique as special boxing type & hidden constructors

[Alexander Kjeldaas]

On Wed, Aug 20, 2014 at 3:07 PM, <p.k.f.holzenspies at utwente.nl> wrote:

>   On Wed, Aug 20, 2014 at 1:47 PM, <p.k.f.holzenspies at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140820/c99ec47e/attachment-0001.html>