Boost logo

Boost :

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


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