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