Re: [boost] review request for boost.context

Subject: Re: [boost] review request for boost.context
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-07-29 09:52:49

> > Am 28.07.2010 19:21, schrieb Hartmut Kaiser:
> >>> The TIB is not changed (only the pointers pointing to the limit and
> >>> base of the stack).
> >>
> >> That will result in problems, I'm sure - at least as soon as you
> >> start moving context's between threads.
> > Could you describe a scenario which will trigger an error, please?
> 
> Anything that uses thread-local variables or fiber-local variables will
> fail if you just run it on another thread or fiber. This can include C
> runtime functions --- errno is typically thread-local, for example.
> 
> >>> AFAIK migrating Win32 Fibers between threads is not possible and
> >>> cloning also not - but maybe I'm wrong in this point.
> >>
> >> Moving Windows fibers between threads is definitely possible.
> 
> > Or do I have to use a special function form the Win32 API?
> 
> You need 3 fibers to move a fiber between threads:
> 
> Thread A is running Fiber 1. It switches to Fiber 2.
> Thread B is running Fiber 3. It switches to Fiber 1.
> 
> Hey presto, fiber 1 has switched threads.
> 
> All is now well, provided code on Fiber 1 doesn't use thread-local
> variables. Recent versions of the MSVC runtime use fiber-local variables
> instead of thread-local ones, so standard C and C++ functions should be
> OK, but e.g. boost::thread uses thread-local variables for things like the
> thread ID, thread_specific_ptr variables and at_thread_exit handlers.

Although this is correct, I would like to emphasize that sometimes it does
make sense to use thread local storage even with fibers. This requires
careful design, but allows to attach data to the OS threads driving the
whole thing. I gues what I want to say is that it's not a good idea to fully
replace TLS with FLS, but both need to complement each other.

Regards Hartmut

---------------
Meet me at BoostCon
www.boostcon.com