[for the 4th time moving this discussion to cafe] On Friday 26 November 2004 08:39, you wrote:
Benjamin Franksen wrote (snipped):
Doesn't that run contrary to Adrian Hey's "oneShot" example/requirement?
Remind me again what Adrian Hey's "oneShot" example/requirement is ...
http://www.haskell.org//pipermail/haskell/2004-November/014766.html
[...]
Furthermore, I have great difficulty in understanding why different threads need different dictionaries. Could you explain why this is useful, or rather, more useful than a global single dictionary?
Consider Data.Unique implemented over lots of processors. If you had a single IORef managed by a single processor used to generate new unique identifiers, there is the danger that that processor will become a bottleneck for the whole system. Much better to have a thread-local or processor-local IORef which generates new identifiers, which you then prepend with a processor tag.
I see. Note that currently there exists no Haskell implementation that is able to make use of multiple processors. See http://research.microsoft.com/Users/simonpj/papers/conc-ffi/conc-ffi.ps Having read http://www.haskell.org//pipermail/haskell-cafe/2004-November/007666.html again, as well as your comments above, I tend to agree that withEmptyDict may indeed be useful. However, the situations you describe are somewhat special. They can and should be handled by explicitly calling withEmptyDict. I still can't see any reason why each single Haskell thread should have its own searate dictionary. Contrary, since it is common to use forkIO quite casually, and you expect your actions to do the same thing regardless of which thread calls them, this would be disastrous. IMO GlobalVariables.hs shouldn't be aware of threadIds at all.
What non-standard libraries have I used (that you don't)?
[...explanation...]
I see. Thanks for the explanation. Ben