Re: [boost] interest in a "signal flow" library?

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-03-04 12:33:53

> From: "Yigong Liu" <yigongliu_at_[hidden]>
> 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