Boost logo

Boost :

Subject: Re: [boost] review request for boost.context
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-07-28 13:21:27


> Am 28.07.2010 16:34, schrieb Hartmut Kaiser:
> > On Windows I'd suggest to fall back to CreateFiber/SwitchToFiber/etc.
> > These functions are not kernel calls, but merely do the context
> > creation/switching. In my experience, it is almost impossible to
> > convince the MSVC C++ runtime libraries to behave properly if you use
> > your own context switching assembly code. OTOH, the measurements we
> > performed shows SwitchToContext being to almost as fast as the hand
> > written assembly code we were using in the beginning.
>
> I find the Win32 Fiber interface ugly - at least the need to call
> ConvertThreadToFiber() and ConvertFiberToThread(). Until VISTA you had no
> Function which tells you if you already running in a fiber or not.

Right, but it's known how to figure that out anyways.

> You could fall back only to some heuristics.

Sure, but those are proven to work :-P

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

> Ofcourse a new SEH chain has to be created and installed
> for each new context.
> So I'd like to know which problems did you encounter with own context
> switching code and MSVC C++ runtime libs.

Yeah, mostly SEH related things. All I could find still is a reference to:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac
kID=100319, otherwise I just don't concretely remember anymore, sorry. The
fiber API works just fine for us, so we stopped looking into the assembly
related problems.

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

Regards Hartmut

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk