Re: [boost] review request for boost.context

Subject: Re: [boost] review request for boost.context
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2010-07-29 07:32:27

Am 29.07.2010 10:36, schrieb Anthony Williams:
> Oliver Kowalke<k-oli_at_[hidden]>  writes:
>
>> 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.

OK - it's up to the user anyway. Using thread-local-storage in different 
threads is always false and boost.context hasn't take special care.

>>>> 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.

So SwitchToFiber() takes care of TIB (setting the members accordingly).
AFAIK only SEH frame, top of stack, current bottom of stack - thats's 
what boost.context does.

> 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,

Hmm - maybe boost.context should take care of fiber data (fs:[0x10]) and 
arbitary data slot (fs:[0x14])?!

Oliver