[Haskell-cafe] Re: [Haskell] Re: Global Variables and IO
initializers
Benjamin Franksen
benjamin.franksen at bessy.de
Fri Nov 26 08:12:12 EST 2004
[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
More information about the Haskell-Cafe
mailing list