Let's continue... -----------------
Several problems I see:
a) (BIG ONE) The shared object link using fcontext crashes!
Using boost_1_46_0
boost-1.46 not tested - use 1.45, please
Building boost_context:
bjam toolset=gcc context-impl=asm architecture=x86 instruction-set=native address-model=64 --with-context variant=release stage
which platform i386? Into the documention I provide for all the platforms (arm, i386, x86_64, mips, ppc) the bjam-options you have to used. - for x86 64bit: bjam toolset=gcc architecture=x86 instruction-set=yorksfield address-model=64 context-impl=asm
Then I compile example link.cpp
Run it
It crashes!
not in my test
b) Building with fcontext is... Too complicated
this is not my fault - boost.build in its current version provides the properites archictecture, instruction-set, address-model as optional - that means that it do not set the values forarchitecture, instruction-set, address-model. boost.context requires those properties in order to select the correct assembler file (see context/build/Jamfile.v2). Vladimir Prus works on a new version of boost.build which provides the properties as regular one so that you don't have to specify them.
Options: context-impl=asm architecture=x86 instruction-set=native address-model=64
instruction-set=nativ is not correct
Why should I specify all these parameters? They should be fully auto-configured.
because in the Jamfile I've to select the assembler file implementing the context switching functions for the correct CPU+address-model#ABI+binary-format -> LINUX on x86_64: architecture = x86, instruction-set = YORKSFIELD, address-model = 64, abi = SYSV, binary-format = ELF
I understand that BBv2 is far from being too friendly and powerful system I still expect that most of parameters should be defined by default otherwise there is no chance that users would be actually able to build it clearly.
as I wrote boost.build doesn't set the values for those properties (architecture, instruction-set, address-model are optional). Even worst Application Binary Interface (ABI -> calling conventions) and the binary-format (ELF, MACH-O, WindowsPE) are not available by the boost.build system.
Other Questions ----------------
1. Please provide a rationale why not both methods are compiled to same library?
Sometimes wouldn't it be better to have option about the type of the method you actually use especially if user may want to have both methods.
Do mean why you can specify to use the context swapping provided by the Operating System or the assembler code (==fcontext)? 1.) ucontext (on UNIX) is less performant (factor 13 as you see in my previous email) compared to fcontext-assembler implementation, because it does system calls to the kernel which consume time in order to preserve unix signal mask. If your require handling UNIX signals you have to use ucontext instead of fcontext (but keep in mind that the signal handler may invoke only obstruction free and async safe functions). 2.) fcontext (UNIX and Windows) does context switching in assembler without any system call and UNIX signal mask preserving. That is the reason beacause it is faster than ucontext (no system calls - kernel calls). If you need UNIX signal handling you could use a separate thread using sigwait() and deliver the signal synchronously (so you don't have the limitations as obstruction free and async safe). 3.) The implementation of Windows Fiber may be equivalent to fcontext but doesn't allow to specify the memory for the stack. You have only the option to set the stacksize (see CreateFiber from Windows Fiber API). That means for each Windows fiber you have a memory allocation and deallocation. With fcontext provided by boost.context you can allocate and reuse your own memory for the context swapping/jumping. An example is boost::tasklets::scheduler from boost.tasklet lib (it caches the stacks used by the boost::context instances - so allocations/deallocations are reduced).
2. Why boost::contexts::context is template class? How does it benefit from this?
The template argument of boost::context specifies the type which abstracts the stack required for your context (remember your execution context is determined by the CPU registers, instruction pointer, stack pointer and the memory area used as stack). This memory must be allocated and deallocated. boost.context provides a stack implementation 'protected_stack' which allocates memory an appends an guard page at the end of the stack so that it protects against exceeding the stack (because it was choosen to small in size). What happens is a segmentation fault/access violation (otherwise I could happen that you overwrite the memory of your own application resulting in unexpected/undefined behaviour). Because it is a template argument you are free to use your own stack class. Oliver