[Haskell] thread-local variables

Einar Karttunen ekarttun at cs.helsinki.fi
Tue Aug 1 05:44:51 EDT 2006


On 31.07 23:53, Adrian Hey wrote:
> Frederik Eaton wrote:
> >On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote:
> >>On 31.07 03:18, Frederik Eaton wrote:
> >>4) the library runs the callback code in Tw where the TLS state is
> >>   invalid. This is even worse than a global variable in this case.
> >
> >If you have threads, and you have something which needs to be
> >different among different threads, then it is hard for me to see how
> >thread-local variables could be worse than global variables in any
> >case at all.
> 
> I haven't been following the technicalities of the particular
> scenario that's under discussion so I don't know exactly
> what either of you mean by "(even) worse than global variables".
> 
> I just want to point out that, as I (and a few others) see it at
> least, top level mutable state (aka "global variables") is
> absolutely necessary sometimes for _SAFETY_ reasons.

I agree that global variables are sometimes the best solution.
My point in the quote was that in the example described
TLS would cause more trouble than global mutable state.

> But I would say that I think I would find having to know what thread
> a particular bit of code was running in in order to "grok it" very
> strange, unless there was some obvious technical reason why the
> thread local state needed to be thread local (can't think of any
> such reason right now).

I have to agree to this. It would be very nice to see good examples
of thread local state in action that would teach us (the sceptics)
why TLS is a good idea in Haskell - and maybe we would learn to
write better code with it. Something more than simply avoiding
a Reader monad / implicit parameters would be nice.

ps. Should we move this discussion to haskell-cafe?

- Einar Karttunen


More information about the Haskell mailing list