[Haskell] thread-local variables

[Frederik Eaton]

> > Here is a naive and dirty implementation. The largest problem is that
> > TypeRep is not in  Ord. An alternative approach using Dynamic would be
> > possible, but I like the connection between the key 
> > and the associated type.
> > 
> > http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/
> > 
> > Not optimized for performance at all.
> 
> You've redefined 'fork'. If I want a library which works with other
> libraries, that will not be an option. The original purpose of my
> posting to this thread was to ask for two standard functions which
> would let me define thread-local variables in a way which is
> interoperable with other libraries, to the same extent as 'withArgs'
> and 'withProgName' are.

I also forgot to mention that if you hold on to a ThreadId, it
apparently causes the whole thread to be retained. Simon Marlow
explained this on 2005/10/18:

m> One could argue that getting the parent ThreadId is something that
m> should be supported natively by forkIO, and I might be inlined to agree.
m> Unfortunately there are some subtleties: currently a ThreadId is
m> represented by a pointer to the thread itself, which causes the thread
m> to be kept alive.  This has implications not only for space leaks, but
m> also for reporting deadlock: if you have a ThreadId for a thread, you
m> can send it an exception with throwTo at any time, and hence the runtime
m> can never determine that the thread is deadlocked so it will never get
m> the NonTermination exception.  Perhaps we need two kinds of ThreadId: a
m> weak one for use in Maps, and a strong one that you can use with
m> throwTo.  But then building a Map in which some elements can be garbage
m> collected is a bit tricky (it can be done though; see our old Memo table
m> implementation in fptools/hslibs/util/Memo.hs).

So this is another problem with your implementation, and another
reason why I want TLS support in the standard libraries.

Frederik

-- 
http://ofb.net/~frederik/