Hi Oliver, On Mar 28, 2011, at 4:03 AM, Oliver Kowalke wrote:
yes - it is dprecated by the new POSIX standard. For instance glibc on ARM doesn't provide ucontext anymore. that was the reason for implementing the functionality in assembler => fcontext (without the limitations of ucontext).
I see. That's a shame. I agree with Artyom that it makes sense for you to create a C API as well. I would have thought C programmers use coroutines too much for POSIX to get away with this. User-level threads are pretty common too, aren't they?
ucontext is wrapped by boost::context - and in the new version of boost.context ucontext will be used only as fallback for platforms where fcontext implementation isn't available. And yes - ucontext is buggy - from its usage (invalid function pointer cast) and behaviour (the 64bit-pointer truncation of arguments with glibc/x86_64).
Well, I'm glad you're "keeping a foot in the door". I hope ucontext will get reincarnated. Seems like they could make it safe just by getting rid of the varargs, if that was the concern. void f(void*) is really all you need.
The documentation contains a chapter 'Configuration', it describes the required bjam command-line arguments for the different platforms:
x86/32bit: bjam toolset0gcc architecture=x86 instruction-set=i686 address-model=64 context-impl=asm
OK, sorry for confusion. I got these settings but for some reason wasn't sure they were working; I am probably successfully using fcontext then. Thanks! Gordon