[fiber] mini review - symmetric a. asymmetric continuation
I've uploaded a new version to boost vault (section 'Concurrent Programming') which contains to fiber implementations - sym_fiber (symmetric fiber/continuation) and asym_fiber (asymmetric fiber/continuation). I'd like to ask for a mini review in order to get a bit feedback if the design is appropriate. Oliver
On Feb 9, 2011, at 10:55 AM, Oliver Kowalke wrote:
I've uploaded a new version to boost vault (section 'Concurrent Programming') which contains to fiber implementations - sym_fiber (symmetric fiber/continuation) and asym_fiber (asymmetric fiber/continuation).
I'd like to ask for a mini review in order to get a bit feedback if the design is appropriate.
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); }
Oliver _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
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
Daniel Larimer wrote:
On Feb 10, 2011, at 3:34 AM, Oliver Kowalke wrote:
Am 10.02.2011 02:10, schrieb Daniel Larimer: 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.
Oliver is working already in a github repository. Maybe you can work together in his current repository. Oliver? You could setup the CMAKE build chain and update the Mac part. HTH, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/fiber-mini-review-symmetric-a-asymmetric-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Feb 10, 2011, at 7:52 AM, Vicente Botet wrote:
Daniel Larimer wrote:
On Feb 10, 2011, at 3:34 AM, Oliver Kowalke wrote:
Am 10.02.2011 02:10, schrieb Daniel Larimer: 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.
Oliver is working already in a github repository. Maybe you can work together in his current repository. Oliver?
You could setup the CMAKE build chain and update the Mac part.
I am still learning git ( I like what I see ). I did check out his git-hub repository, but I was unable to figure out how 'overlay' his repos on a working boost chain or pull out just the parts he was using. Besides, I would like to support the efforts of Boost.CMake and/or Ryppl, both of which use cmake and a 'modular' approach allowing me to checkout 'just boost context' all in one directory and then collaborate on that repository. Because git does not allow you to manage externals in the same way subversion does (pointing at any subtree of the repo), it makes sense to keep each library in a self contained git module that does not split itself into boost/context and lib/context parts. Right now I see advantages in Boost.Cmake over Ryppl in that Ryppl is more tied to git, where as Boost.Cmake is more flexible with respect to getting the sources. I have checked out and built the projects for both and it seems like, in the short term Boost.CMake has the advantage over Ryppl, but in the long-term I think Ryppl will be the best. Either way, the module structure should be fairly close, thus making it easy to port from one system to the other or even support both at once. In this way we can give feed back to the developers working on these ideas. Is anyone doing active development of their boost components under either of these modular systems? Anyway, I agree with the creator of Ryppl when he said at Boostcon 2010 that the boost build process sucks the joy out of development. I want to focus on actual code, not fighting with a difficult boost-centric build system that cannot even handle (on Mac OS X ) passing bjam extra options required by Boost.Context without messing up the commands fed to sh. I have already spent 16+ hours just trying to get my 'environment' set up in a way that I can efficiently stay up to date with the trunk, submit patches that are easily merged, and work on my own private libraries. Perhaps a veteran boost developer could share their 'day-to-day' process for staying up to date, making patches, etc. Perhaps it is not so bad if you know bjam through and through.
HTH, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/fiber-mini-review-symmetric-a-asymmetric-... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am 10.02.2011 16:34, schrieb Daniel Larimer:
Anyway, I agree with the creator of Ryppl when he said at Boostcon 2010 that the boost build process sucks the joy out of development. I want to focus on actual code, not fighting with a difficult boost-centric build system that cannot even handle (on Mac OS X ) passing bjam extra options required by Boost.Context without messing up the commands fed to sh. I have already spent 16+ hours just trying to get my 'environment' set up in a way that I can efficiently stay up to date with the trunk, submit patches that are easily merged, and work on my own private libraries.
Did you contact the boost.build developer regarding to this issue?
participants (3)
-
Daniel Larimer -
Oliver Kowalke -
Vicente Botet