From: Rick DeNatale <rick.denatale@...>
Date: 2008-01-11T03:51:07+09:00
Subject: Re: Fibers clear thread-specific data?

On 1/9/08, MenTaLguY <mental@rydia.net> wrote:
> On Thu, 2008-01-10 at 07:55 +0900, MenTaLguY wrote:
> > > This hash may very well hold onto the last reference to the data
> > > structures I'm trying to store, so it'd be a pity if they got garbage
> > > collected...
> >
> > The last non-weak reference should be from the fiber's Thread.current[]
> > map, which goes away when the fiber is destroyed.  The data structures
> > should go away at that time too.
>
> Thinking about it, rather than a global hash, using an instance variable
> in thread objects might be the best choice, since you do actually want
> to tie it to the lifetime of threads rather than particular fibers.

The more I think about this, the more I think that Frank's question is
a good one.

Fibers aren't really at all about concurrency, they are about flow of
control. Personally I think that it's as wrong for two fibers on the
same thread to get two different values of the same thread-local as it
would be for two methods running the same thread to do so.

Googling around, I notice that Windows, which has fibers, has both
Thread local variables and Fiber local variables.

Whether or not Fiber local variable are needed is debatable, but I'm
pretty sure that thread locals as they are currently implemented in
1.9 for fibers is highly suspicious if not broken.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/