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