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

Subject: Re: [boost] [fiber] mini review - symmetric a. asymmetric continuation
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-02-10 04:07:11

On Feb 10, 2011, at 3:34 AM, Oliver Kowalke wrote:

> Am 10.02.2011 02:10, schrieb Daniel Larimer:
>> I am working on a project that will be using your fiber library in a manner similar to how sym_fiber is intended.  Before you released this update I was planning a design using the asym_fiber  (which looks like the old 'fiber') that would simply call 'run()' on the fiber it intended to 'switch to' under the assumption that I could have any other fiber 'resume' by calling run on it again.  The only apparent difference is that with 'yield()' you go back to the caller and with run() you go to some other context (which could also be the caller).
>> 
>> Perhaps I am missing something fundamental, but I didn't see a need for two different fiber's.
>> 
>> fiber a(funcA);
>> fiber b(funcB);
>> 
>> void funcA()
>> {
>> 	b.run();  // == a.switch_to(b);
>> }
>> void funcB()
>> {
>> 	a.run(); // == b.switch_to(a);
>> }
> 
> asymmetric fiber provide two control-transfer operations:
> asym_fiber::run() activates the continuation point of this fiber == execution control is transfered to the fiber
> asym_fiber::yield() saves the continuation point of the fiber ==
> execution control is transfered to the invoker of this fiber (asym_fiber::run()).
> for asym_fiber it is characteristic that it returns always to its invoker. Providing two functions makes the semantic of the transfer operations more explicit: run() -> activate, yield() -> deactivate.
> With only one operation it would not be clear if the fiber will be activated or deactivated.
> 
> a sequence of invocation with asymmetric fibers looks like this:
> 
> fiber A -> fiber B -> fiber A
> fiber A -> fiber C -> fiber A
> fiber A -> fiber D -> fiber A
> 
> each invocation of fibers B, C, D returns to fiber A.
> 
> 
> symmetric fibers provide only one transfer operation:
> sym_fiber::switch_to() transfers execution control to a arbitrary fiber
> In contrast to asym_fiber the sym_fiber does not return to its invoker.
> The fiber switch is more explicit
> 
> a sequence of invocation with symmetric fibers looks like this:
> 
> fiber A -> fiber -> fiber C -> fiber D -> fiber A
> 

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.

I could see a more unified approach being something like:

fiber A (runA)
fiber B (runB)

runA()
{
        B.run(); // async run() would store the 'caller'
        B(); // optional syntax, looks more like a void() coroutine.
}
runB()
{
        B.switch_to(B.caller());  // == yield()
        B.yield(); // optional syntax.
}

I think offering both interfaces on one generic fiber type is better than making the user pick at construction what syntax they want to use.

The only question becomes is there a performance penalty for 'saving' the caller and if so, then the difference between run() and switch_to() would be an important distinction.

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.  

> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost