Re: [boost] Boost.Context review result

Subject: Re: [boost] Boost.Context review result
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-05-14 17:58:59

* The context class will not be templated any more, and the use of type erasure will ensure that.

context must be templated ->  reason is that hte stack must be owned by context ->  see rational section in documentation

* At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them.

this has to be done by higher level libs - you could use futures for instance (as boost.strand does)

3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice.

asm impl for windows should be ok - all boost_fcontext_t functions are leaf-functions using tail calls - concerns from Holger do apply only to non-leaf functions

5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class.

This coding style can not be used toghether with move operations - explanation is in rational section in boost.context docu.

10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values.

boost.build is the default build system for boost libs - it has its limitations. those limitations are that the required boost.build properties as 'architecture', 'instruction-set' and 'address-model' are optional instead default. That means that optional properties are not set by the boost.build system. The user hast to specify those properties. In the documentation I wrote a section listing for all supported platforms the required property values.
The mentioned properties are required for alternative selection in the Jamfile in order to select the correct assembler file.
Vladimir told me that he is already working on boost.build so that 'architecture', 'instruction-set' and 'address-model' become default properties.

1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back.

As described above this doesn't work - please take a look in the docu.

2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts),

boost.context was made to be used by my other lib boost.strand which provides a scheduler for such context objects - I think it is not a limited case.

regards,
Oliver

Am 14.05.2011 23:29, schrieb Vicente Botet:
> Oliver Kowalke wrote:
>> Hi,
>>
>> thank you Vicente for your job as review manager.
>>
>> I've reworked the library according to the suggestions of the review -
>> but not all requests could be fulfilled.
>> The new version (boost.context-0.7.0.zip) is published on boost vault
>> and the docu can be read here :
>> http://ok73.ok.funpic.de/boost/libs/context/doc/html/ .
>>
>
> Oliver pleas,  be free to report which points can not be fulfilled.
>
> Best,
> Vicente
>
> --
> View this message in context: http://boost.2283326.n4.nabble.com/Boost-Context-review-result-tp3521970p3523207.html
> Sent from the Boost - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>