[Haskell] thread-local variables
frederik at a5.repetae.net
Sat Aug 5 23:23:45 EDT 2006
> > 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.
More information about the Haskell