Unique as special boxing type & hidden constructors

Wed Aug 20 14:47:41 UTC 2014

Dear Max, et al,

Here's hoping either you are still on the mailing list, or the address I found on your website (which says you're a Ph.D. student, so it's starting to smell) is still operational.

I'm working on redoing some Unique-stuff in GHC. Mostly, the code uses Unique's API in a well-behaved fashion. The only awkward bit I found is in BinIface.getSymtabName, which git blames you for ;)

I just wanted to ask: Why does this functions do all the bit-masking and shifting stuff directly and with different masks than anything in Unique? Is there a reason why this doesn't use unpkUnique? The comments in Unique state that mkUnique is NOT EXPORTED (the caps are in the comments, I'm not shouting), but they are, it seems, specifically for BinIface. I would like to get rid of this, but dare not hack away in the dark.

Regards,

Philip

________________________________
From: Alexander Kjeldaas <alexander.kjeldaas at gmail.com>
Sent: 20 August 2014 15:48
To: Holzenspies, P.K.F. (EWI)
Cc: Simon Peyton Jones; ghc-devs
Subject: Re: Unique as special boxing type & hidden constructors

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

On Wed, Aug 20, 2014 at 1:47 PM, <p.k.f.holzenspies at utwente.nl<mailto: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/a6b905c6/attachment.html>