[Haskell] thread-local variables

Einar Karttunen ekarttun at cs.helsinki.fi
Sun Aug 6 06:36:15 EDT 2006

On 06.08 02:41, Frederik Eaton wrote:
> Also, note that my proposal differs in that thread local variables are
> not writable, but can only be changed by calling (e.g. in my API)
> 'withIOParam'. This is still just as general, because an IORef can be
> stored in a thread-local variable, but it makes it easier to reason
> about the more common use case where TLS is used to make IO a Reader;
> and it makes it easier to share modifiable state across more than one
> thread. I.e. if modifiable state is stored as 'IOParam (IORef a)' then
> the default is for the stored 'IORef a' to be shared across all
> threads; it can only be changed "locally" for a specified action and
> any sub-threads using 'withIOParam'; and if some library I use decides
> to fork a thread behind the scenes, it won't change my program's
> behavior.

Perhaps a function like this would solve all our problems:

-- | Tie all TLS references in the IO action to the current
-- environment rather than the environment it will actually
-- be executed.
tieToCurrentTLS :: IO a -> IO (IO a)

> I think it is a good idea to have stdin, cwd, etc. be thread-local.

How would this work together with the FFI?

> I don't understand why the 'TL' monad is necessary, but I haven't read
> the proposal very carefully.

The TL monad is necessary to make initialization order problems go

- Einar Karttunen

More information about the Haskell mailing list