Re: [boost] [context] Implementation comments

Subject: Re: [boost] [context] Implementation comments
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-17 12:54:02

----- Original Message ----- 
From: "Oliver Kowalke" <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, January 17, 2011 5:55 PM
Subject: Re: [boost] [context] Implementation comments

> Am 17.01.2011 13:36, schrieb vicente.botet:
>> * Pimpl: The use of Pimpl idiom for a low level service 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). 

We should be able, isn't it? If we are not able now we need to see what is missing in Boost.Config to achieve it.

> 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?

Boost.Context is much more low level than Boost.Thread. 
 
>> * 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.

Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments?
In any case I find the use of mmap a bad choice when no protection is required.
 
>> 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.).

Of course. But the library can provide a basic interface that hides whether you use ucontext_t or your own assembler implementation.
 
>> 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.

boost::static_context<N> could inherit from boost::context. But I'm not requesting this for the moment.

Best,
Vicente