From: "Yigong Liu" <yigongliu@gmail.com> Subject: Re: [boost] interest in a "signal flow" library?

Signal_links looks like a nice light-weight feature to have when developing event dispatching applications using Boost.Signal. From its current syntax, looks like it will work most naturally for linear pipeline and tree like connection topologies, for more complicated connection topologies (such as mesh or acyclic graph), we will have to break it up into pipeline or trees and set up them in several steps? that said, it still makes code cleaner and clearer. could we have some samples showing dynamic reconfiguration works (adding/removing new senders/recvers)?

Yes, I think the operator based approach might not extend too well to more complicated topologies, so several steps would be necessary. Unless we added direct support for commonly used topologies (e.g., mesh), which could be nice. I do need to extend the reconfiguration capabilities and examples. I'm hoping to get around to incorporating some of the more easily addressable feedback I've received into the next iteration of the implementation / documentation within the next week.

The scenario Paolo mentioned: "video_generator >>= ( effect1 && effect2 ) >>= image_sum >>= display" in fact the middle part of it "( effect1 && effect2 ) >>= image_sum" is so called "join" pattern in message passing. i have written a boost based framework (http://channel.sourceforge.net) for asynchronous events and message passing which support both choice/join patterns, executing callbacks in thread pools, push/pull models and other stuff which you may find interesting, although it doesnt have the elegant api of Boost.Signal.

I gave it a brief glance and did find it interesting - I really like the distributed aspect. I will look into it more. Thanks, Stjepan