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