Hi All,
On 7/31/06, Einar Karttunen wrote:
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
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 update
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.
What about a design with 10 worker threads taking req
On Sun, Jul 30, 2006 at 12:35:42PM +0300, Einar Karttunen wrote:
> On 29.07 13:25, Frederik Eaton wrote:
> > I think support for thread-local variables is something which is
> > urgently needed. It's very frustrating that using concurrency in
> > Haskell is so easy and nice, yet when it comes to IO
On 29.07 13:25, Frederik Eaton wrote:
> I think support for thread-local variables is something which is
> urgently needed. It's very frustrating that using concurrency in
> Haskell is so easy and nice, yet when it comes to IORefs there is no
> way to get thread-local behavior. Furthermore, that on
