On Mon, Jul 31, 2006 at 03:54:29AM +0300, Einar Karttunen wrote: > On 30.07 11:49, Frederik Eaton wrote: > > No, because the thread in which it runs inherits any thread-local > > state from its parent. > > So we have different threads modifying the thread-local state? > If it is a copy then updates are not propagated.
As I said, please read my code. There are no "updates". > What about a design with 10 worker threads taking requests > from a "Chan (IO ())" and running them (this occurs in real code). > To get things right they should use the TLS-context relevant > to each "IO ()" rather than the thread. I could see how either behavior might be desirable, see below. (*) > (snip) > Usually I just define one custom monad for the application which > wraps the stack of monad transformers. Thus changing the monad stack > does not affect the application code. A quite clean and efficient > solution. That does sound like a clean approach. However, I think that my approach would be cleaner; and in any case I think that both approaches should be available to the programmer. > My main objection to the TLS is that it looks like normal IO, > but changing the thread that evaluates it can break things in ways > that are hard to debug. E.g. we have an application that uses > TLS and passes an IO action to a library that happens to use > a pool of worker threads that invisible to the application. > Or the same with the role of the application and library reversed. I don't think it's necessarily such a big deal. Presumably the library with the worker threads will have to be invoked somewhere. One should just make sure that it is invoked in the appropriate environment, for instance with the database connection already properly initialized. (*) One might even want to change the environment a little within each thread, for instance so that errors get logged to a thread-specific log file. > Offering it up as a separate library should be ok as it would > be very easy to spot and take extra care not to cause problems. That's good to hear. Regards, Frederik -- http://ofb.net/~frederik/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
