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

Subject: Re: [Boost-users] [dataflow.signals][thread_safe_signals] How to alter the Calling of chained signals
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-09-06 16:18:48

On Tue, Sep 2, 2008 at 7:50 AM, Manuel Jung <gzahl_at_[hidden]> wrote:
>
> The current implementation does not cover priority or smart threadpools. I
> need to submit a priority type (for instance just an int) with the first
> submit and this value needs to be submit everytime make_async submits a new
> task. This priority value changes with every data submitted to the dataflow
> network. And it is very importend: You wont need possible breakpoints in
> your dataflow network (the make_async calls), if there is no priority
> system. (Well it would make sense if you split signals with "|" opeartor,
> so the rest of the dataflow could be parallelized..)
>
> II have antother thaught: The make_async filter is ok as interface, to split
> the dataflow. But i don't like that i loose control over the task object.

I am trying a new approach:
http://svn.boost.org/trac/boost/browser/sandbox/SOC/2007/signals/libs/dataflow/example/threadpool/threadpool_component_example.cpp

With this one, the pool is associated with with a component, rather
than a connection.  That way, the task can be stored and retrieved
from outside at some point.  I'm not sure about one thing though - in
threadpool examples I've looked at, there is one thread that submits
the tasks, and then the same thread controls the tasks.  Here, we have
worker threads creating subsequent tasks, so they would need to get
the task object to the main controller thread somehow.  Does the
threadpool object provide access to all submitted and running tasks,
maybe the main thread can just get them from there? Or, the
async_component can store all created tasks internally and provide
access to them.

> If i have no task object, i am not able to interrupt that task. And
> interruptions of tasks would be very handy to make the program more stable.
> I could control the runtime of tasks and interrupt and kill them, if they
> didn't respond.

I can try something like this.

> Maybe this is out of the scope of dataflow.signals, but i
> think i would prefer an implementation of dataflow with futures, if that is
> possible. I think that would make the integration of the threadpool library
> much more natural. I'm not very familiar with futures yet, still learning,
> how to use them best. But i will think about this and let you know if i can
> think of a way to do it.
>

I think the futures interface might not align the best with
Dataflow.Signals, but we could try to put together a new Dataflow
framework that would be specific to the Threadpool library and use
futures.

> I don't no how much i could contribute to your rewrite of the dataflow
> library, but altough it would be nice if you would keep me informed. At the
> moment i have relativly much free time, but by the time the new semester
> starts, my time will be much shorter.
>

I will keep you informed.

Best,

Stjepan