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

26 Aug 2008

      On Mon, Aug 25, 2008 at 11:40 AM, Stjepan Rajko  wrote:
...
On Sun, Aug 24, 2008 at 11:51 AM, Manuel Jung  wrote:
...
An example would be really great! Do you know the proposed threadpool
library?
I just downloaded it and need to study it a bit.  When I figure out
how to use it, I'll work on the example.
OK, I have a working example.  You can find it in the boost sandbox:

http://svn.boost.org/svn/boost/sandbox/SOC/2007/signals/libs/dataflow/exampl...

The user code looks like this:

typedef
    tp::pool<
        tp::fixed,
        tp::unbounded_channel< tp::fifo >
    > threadpool_type;

threadpool_type pool(tp::max_poolsize(5));

typedef boost::signals::storage source_type;
typedef boost::signals::function filter_type;

// our components
source_type source(1);
filter_type increase(inc_fn);
filter_type increase2(inc_fn);
filter_type increase3(inc_fn);
filter_type increase4(inc_fn);

// our network
//  increase >>= increase2 will be in its own thread
//  increase3 will be in its own thread
//  increase4 will be in its own thread
source
    | (make_delay(pool, increase) >>= increase2)
    | (make_delay(pool, increase3) >>= make_delay(pool, increase4));

// submit the first task
submit(pool, source);

Like you said, delay might not be the best name, but works for now.  A
couple of comments:

* The example is hard-wired to a void(int) signature.  It wouldn't be
hard to generalize, if there is interest.

* The example above uses Boost.Signals (not thread_safe_signals).
This is unsafe, but in my experience as long as the signals get
connected before the threading starts, it works ok.  A couple of minor
things need to be addressed with thread_safe_signals before it will
work as a drop-in replacement with Dataflow.Signals - I'll see if I
can get them integrated.

* I don't use chained_submit - instead, the delay object will do a
regular submit when it gets its input.  This was more in line with the
push-oriented design of Boost.Signals.  To use chained_submits and
futures would require either using a pull-based network (each
component taking in the input as the argument and returning the
result), or propagating the final result back through return values.

Thoughts?

Stjepan