Re: [boost] [context] Implementation comments

Subject: Re: [boost] [context] Implementation comments
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-20 02:23:56

----- Original Message ----- 
From: "Oliver Kowalke" <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, January 19, 2011 9:58 AM
Subject: Re: [boost] [context] Implementation comments

>> >>> 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?
> 
> mallolc() does add some managment stuff into the allocated memory chunk - and this what you realy don't want on your stack.

Why?
 
>> >> 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?
> 
> malloc() uses internally mmap(). it saves only some additional data on the allocated memory chunk.

Yes, but not at every call :)
 
>> > 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.
> 
> I refered to ucontext_t, fcontext_t and Windows Fibers - sorry to be unspecific in this point.

What I meant is that Boost.Context could provide a low level inteface (similar to the one ucontext_t provides) which will be implemented possibily in assembler, use ucontext_t or Windows Fibers. 

namespace boost {
namespace contexts {
  struct fcontext_t {...};
  int get_fcontext( fcontext_t& fc);
  int set_fcontext( fcontext_t const& fc);
  int swap_fcontext( fcontext_t & ofc, fcontext_t const& nfc);
  int fill_fcontext( fcontext_t & fc, std::size_t size, void* stack_ptr, fcontext_t * next);
  int make_fcontext( fcontext_t & fc, void (* fn)( void *), void * p);
}}

With this minimal inteface we can create higher abstractions with a lower overhead.

Note that std::size_t size, void* stack_ptr could be replaced by an abstraction that provides both informations.

> Some additional points to your request for separating stack allocation from context creation: Windows Fiber API (which is used as an implementation detail on Windows) doesn't allow to pass an self-allocated stack to CreateFiber(). So this would break the interface of boost::context.

I think the interface of boost::context must be independent of the implementation details of a specific platform if in this way the interface could allow a better implementation on most of the other platforms. Instead of reducing the interface we need to make it as open as we can.

The library could provide some stack allocation mechanisms which will take care of whether the implementation is using the Windows Fiber API. A user should be able to define its own allocation stack mechanism and be as efficient as possible if s/he takes in account detail implementation information provided by Boost.Context through for example a macro, BOOST_CONTEXT_MANAGE_THE_STACK or somthing like that.

Vicente