Re: [boost] [context review] Several Questions

Subject: Re: [boost] [context review] Several Questions
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-21 17:46:58

> 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