Re: [boost] [context] Implementation comments

Subject: Re: [boost] [context] Implementation comments
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-19 03:05:11

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

> Am 17.01.2011 18:54, 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.
> 
> how would you evaluate the properties applied to bjam in the source 
> code? this is not possible

Well, we were able to go to the Moon long time ago. We can add to the project 

<architecture>XXX:<define>BOOST_ARCHITECTURE_XXX 

I guess you have see the implementation of Boost.Coroutine. Boost.Coroutine has Context concept and a model of Context is defined depending on a cetain number of compile time factors (compiler, platform, ..). Of course all the context operations can be inlinined helping surely to improve the performances.

>>> 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.
> 
> why? thread and context are resources - I don't see context more low 
> level than thread

OK. I could admmit move semantics is a good thing for any user resource. 

Couldn't we have a more low level context abstraction that is non movable and that could be used as a member field in higher abstracions as coroutines.

>>>> * 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?
> 
> some ABIs require some hidden space at the begin of the stack and 
> especially alignment

Can malloc be used to get this hiden space?
 
>> In any case I find the use of mmap a bad choice when no protection is required.
> 
> why? mmap() is a good choice if you require aligned memory even if you 
> do not use guard pages.

Can malloc be used to get aligned memory?

>>>> 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.
> 
> I don't understand your note - the lib does provide an abstraction over 
> ucontext, fcontext, fibers etc.

Note that I didn't talk of fibers :) As for me fibers are a higer level abstraction. Of course Fibers can be used as a detail implementation of the Context concept, but his interface shouldn't be considered when defining the one for Context.
 
>>>> 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.
> 
> sorry - I don't see any benefit of such a construction. why would you 
> want to have different types for a context which only differ in the 
> stacksize?

To improve the efficience of Context construction and destruction. Forget this for now please.

Best,
Vicente