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 _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
