Am 15.05.2011 11:10, schrieb Vicente BOTET:
I have added the rationale
"Stack as template argument
A context must own stack because it must control the life time of the stack, for instance if the destructor of context has to unwind the stack the nthe stack must be still valid. For reusage of the stack it can be released - unwinding will not be done and the context can be used anymore. In orde to release the stack its type must be known by context therefore context takes the stack type as template argument. Usualy an application uses instances of _contexts_ with the same stack type instead of mixing contexts with with different stack types."
I don't think that this is a valid rationale. Type erasure should allow you to do what you need. See the comments from Giovanii on how to do it.
boost::context has stack_type context::relase_stack() whic hremoves the stack from the context instance (otherwise the destructor of boost::context destroys the stack). protected_stack stack = ctx.release_stack(); boost::contexts::context<> ctx( fn, boost::move (stack), false, true); If you remove the stack type from boost::context you are required to implement a test function in order to check for the stack type to returned by release-stack() function. I think this is counter-intuitive. Usually instances of boost::context are instantiated with the same stack type - I'm sure mixing contexts with different stack types will be rare.
* 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) After the split on a high level context class and a C-like API, the class context a high level class that should provide some user friendly features. I think higher abstractions should handle this in its own way! The current solution forces the user to think about the behaviour of its application if exceptions occur and how its code handle the exceptions. Otherwise the application terminates. This is the same behaviour which boost::thread expresses.
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. I think you have not understood how Giovanii proposed to do that, but maybe I'm wrong.
I think I understood what Giovanii suggested - I've tried several implementations/versions and the conclusion is that it does not work together with move support and stack unwinding.
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. I have just a question: How people running the regression test will do to build your library and run your tests?
I've a section in the documentation which describes how the bjam command-line has to look like for several platforms - http://ok73.ok.funpic.de/boost/libs/context/doc/html/context/installtion.htm... ARM, UNIX, aapcs, elf bjam toolset = gcc architecture = arm MIPS (32bit), UNIX, o32, elf bjam toolset = gcc architecture = mips1 I386, UNIX, sysv, elf bjam toolset = gcc architecture = x86 instruction-set = i686 address-model = 32 I386, UNIX, sysv, elf bjam toolset = intel architecture = x86 instruction-set = i686 address-model = 32 I386, Windows, ms, pe bjam toolset = msvc-9.0 architecture = x86 instruction-set = i686 address-model = 32 PowerPc (32bit), UNIX, sysv, elf bjam toolset = gcc architecture = power address-model = 32 PowerPc (64bit), UNIX, sysv, elf bjam toolset = gcc architecture = power address-model = 64 X86_64, UNIX, sysv, elf bjam toolset = gcc architecture = x86 instruction-set = yorksfield address-model = 64 X86_64, UNIX, sysv, elf bjam toolset = intel architecture = x86 instruction-set = yorksfield address-model = 64 X86_64, Windows, ms, pe bjam toolset = msvc-10.0 architecture = x86 instruction-set = yorksfield address-model = 64 regards, Oliver