[Haskell] thread-local variables

Adrian Hey ahey at iee.org
Mon Jul 31 18:53:54 EDT 2006


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.

<BTW>
If anybody still doesn't "get it" re. why we need top level
mutable state, the point is not to avoid explicit state handle
threading. The point is to avoid exposing "newState" constructors
as part of the IO library API (thereby making it invulnerable to
accidental state "spoofing").

If you're going to deny library users the ability to create new
state handles then you have to make at least one "ready made"
state handle available at the top level. It just so happens
that in the common case where there can be only one such state
handle (for safety reasons) then you can completely eliminate
this from the exposed API.
</BTW>

As for the subject under discussion (thread local state), I am
personally sceptical about it. Why do we need it? Are we talking
about safety or just convenience/API elegance? I've never
encountered a situation where I've needed thread local state,
(but this does not necessarily make it evil:-)

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).

My 2p..

Regards
--
Adrian Hey





More information about the Haskell mailing list