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 away. - Einar Karttunen _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell