Re: [boost] [context] Implementation comments

Subject: Re: [boost] [context] Implementation comments
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-01-17 11:55:39

Am 17.01.2011 13:36, schrieb vicente.botet:
> * Pimpl: The use of Pimpl idiom for a low level sevice seems to me overdesigned.

I think it is not. With pimpl I can hide the implementation details 
inside the cpp-files. Otherwise I would have to mess up with compiler, 
architecture etc. in the header. I could not decide in the code if 'bjam 
toolset= architecture= instruction-set= address-model=' or 'bjam 
toolset=' was used (distinction between OS stack switching or via 
fcontext_t). With the current solution thios is done via property 
matching inside the Jamfile.
The pimpl is also used for an efficient move-implementation.

> * Movable: Why do we need to make context movable? Couldn't unique_ptr<context>  be used to move contexts.

Why is boost::thread implemented with move-semantics?

> * Stack and protection: I think that where the stack memory is located and whether it is protected or not are concerns that are  independent from the context library. I would add to the context creation two parameter: the pointer to the stack and the stack size, and let the user the management of whether this memory is protected or not. The following code should IMO be on the user side

Some requirements must be fulfilled by the stack (alignment, hidden 
range for arguments) which the use may not take care of.

> Maybe the library should provide the thin layer over ucontext (i.e. the fcontext implementation detail functions).

It was intented that the lib hides the concret implemntaion (ucontext_t, 
fcontext_t etc.).

> We could have in addition some kind of static_context that have the stack size as template parameter and contains itself the stack memory area.

If the stacksize is passed as an template arg the boost::context<> would 
evaluate to different type for each stacksize (boost::context< 1 > is 
another type than boost::context< 2 >). I don't see the benefit.

so long,
Oliver