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

Stjepan Rajko wrote: Hi, Here are some of my thoughts. Still not ver much time, more around the weekend.

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... I checked out the whole dataflow from sandbox. Example compiles and runs fine.

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);

This seems very usable. I also like that you are able to add filters to different pools.

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.

I need to have it generalize. Would be great if you could do it, otherwise, i'll try at the weekend.

* 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.

Hmm. thread_safe_signals are needed too. There will be new signal connections after the threading.

* 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.

That is ok with me. I would prefer all the tasks to be added at the beginning (because of an easier priority handling of the queue), but i can this way too, i think.

Thoughts?

Seems very great so far. This way you can do late evaluated dataflow networks :-). Just create a pool and make a dataflow network (even a cyclic! :-)) and you could evaluate it step for step, depending by the threadpools queueing pollicy. Thanks for what you did so far :-). I like the dataflow lib. Can i help writing some code, the generalization for all data types or something else? I just don't know the inside of the dataflow library that good, it would take much longer, if i try to do it... but im of course willing to help. Maybe an other example?

Stjepan

Kind Regards Manuel