Re: [boost] [context] Implementation comments

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

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

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

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

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

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

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