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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-02-20 13:13:53

> Tobias Schwinger wrote:
>
> Yes, I think (if done right) this one will be useful for all kinds of
> software. I'll post a more detailed reply later, after having a look at
> the code.

Thanks for your feedback - I look forward to your reply.

> I think you need a pulling evaluation scheme: Making the (final) sink
> pull rather than the (possibly void-) source push:
> In your example, a Timer would request the Display to be updated, which
> in turn would requests an Image ... and so on, until finally a frame is
> pulled from the video input.
> This way operator nodes (with 1 source >=1 sink) and caching (to not
> reevaluate unchanged paths) become much easier to implement. So much
> easier, that I'm not even sure pushing evaluation is needed at all.

This is a good idea... I haven't thought about pulling, but I think
the current mechanism would support that as well.  The key to be to
implement the components so sending the signal serves as a request,
and the slot function returns the requested data.  The Boost.Signals
combiner mechanism could be used to combine data when it needs to be
pulled from multiple components (although the current implementation
of signal_link doesn't replicate all of the optional template
arguments of boost::signal, that would be an easy add-on).

In that case, if the components were reimplemented so that they
returned the requested value, the flow would be specified as display
>>= database >>= ... >>= video_generator and work as you mention
above.  I will try to add some examples to the documentation when I
get a chance.

I think may work better in a lot of cases, but the pushing evaluation
might be a little more straightforward to use in cases when there is
branching - I'll try to come up with some concrete examples of that
too.

There may also be a way to convert a push-based signal network into
something that simulates pulling.  For example, if you take something
that works as source>>=processor where the source can be signaled to
send data, you can also add a "wrapper" component which, on request,
signals source to send data, grabs the output of the processor on the
other end, and returns it to the caller.  I.e., the complete network
would look something like wrapper >>= source >>= processor >>=
wrapper, and by executing wrapper.DoYourThing() you would get back the
output of the processor.

Thanks again for the feedback,

Stjepan