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
Hmm - maybe boost.context should take care of fiber data (fs:[0x10]) and
arbitary data slot (fs:[0x14])?!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk