Re: [boost] [fiber] mini review - symmetric a. asymmetric continuation

Subject: Re: [boost] [fiber] mini review - symmetric a. asymmetric continuation
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-02-10 05:37:19

Am 10.02.2011 10:07, schrieb Daniel Larimer:
> You have essentially stated my understanding of the context switching.  It seems like the only thing you gain is the 'automatic link' back to the caller from the calle and thus an implicit calle.switch_to(caller) upon return from the fiber method.   Having to write code to deal with an entirely new type and 'concept' when you could simply add a switch_to() method in addition to a yield() method seems a bit overkill and doubles the amount of code you must maintain and document.

Because asymmetric fiber and symmetric have different 'concepts' 
(behaviour) both classes have different interfaces and therefore two 
classes exists. Seams to be a valid class design for me.
I don't see the requirement to integrate both interfaces into one class.
Of course you could implement one kind of fiber on behalf of the other.

> Considering the degree to which we appear to be collaborating with respect to Mac OS X support, I would like to establish an easier development process based upon:
> https://github.com/bytemaster/Boost.CMake
> I have started a module for Boost.Context https://github.com/bytemaster/boost_context and will be creating modules for fiber, task, move, and other unofficial dependencies.  If you would consider working with me to adopt CMake based modular approach to developing these libraries, I would greatly appreciate it.   Otherwise, it it just too difficult to collaborate and do Mac OS X testing for you under the BJam monolithic zip-file based patches.
> At the moment the module only works for libtask supported OS's.  I need to add the CMake options to conditionally compile your various fcontext implementations.

Hmm - I'm not familiar with cmake. I'll think about it.

Oliver