Re: [Boost-users] [dataflow.signals][thread_safe_signals] How to alter the Calling of chained signals

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-08-24 13:03:28

On Sun, Aug 24, 2008 at 8:36 AM, Manuel Jung <gzahl_at_[hidden]> wrote:
> Hi!

Hello,

>
> I want to use dataflow.signals, which is build on top of
> thread_safe_signals.

Do you mean that you would like to use it, or are using it, on top of
thread_safe_signals?

> Each call of a producer (each signal) is put into a
> threadpool. Now i want not to execute the whole chain of data processing at
> once, but just one chain link at the time and put a new task to the
> threadpool than.
> The goal is that i can put rather complex and long (running) dataflow chains
> in the threadpool, which are divided into many pieces, so the threadpool
> can often decide which task is most important.
>

This is a very nice use case.  Are you using any particular threadpool
implementation?

> So how can i alter the call of the next signal in a signal network/chain?

I can see two ways of doing this.  One is to leave the
signal/connection semantics the same but change the semantics of the
receiving component, to where the receiver adds a task to the
threadpool upon receiving the signal (and makes sure that the
threadpool task either reports back when it is done, or knows how to
launch the next threadpool component).  The syntax would maybe look
something like this:

// the components are task launchers
launcher<task1> component_a(some_threadpool);
launcher<task2> component_b(some_threadpool);

// connect them
component_a >>= component_b;

// start the processing chain
component_a(data_for_task_a);

The other way is to change the semantics of connecting, to where the
connection takes care of entering the receiving component into the
threadpool.  The syntax would be:

// the tasks themselves are the components
task1 component_a(some_threadpool);
task2 component_b(some_threadpool);

// connect the tasks directly
component_a >>= component_b;

// start the processing chain
component_a(data_for_task_a);

I wouldn't mind putting together a little example of something like
this.  Do you have a preference for either the above approaches?  The
first one would fit neatly into the existing dataflow.signals network,
and for the other one we would have to implement a new type of
connection.  Not sure which one would be easier.

Stjepan