Hey!
On Tue, Sep 2, 2008 at 7:50 AM, Manuel Jung
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/datafl... I have looked at the new example. I think it is a good approach to make a async component from a normal component. The first example with the inc works fine, but the 3rd (2nd is disabled, but looking forward to this kind..) seems not to work right? My output is e.g.: adding task tick 1... adding task tick 2... adding task tick 3... adding task tick 1... adding task tick 2... adding task But since the network is just "tick_starter >>= ticker1 >>= ticker2 >>= ticker3 >>= ticker1;", the last "tick 2..." is too much, isn't it?
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.
Hm, I'm not sure about this, i will try to investigate about it.
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.
Great, Greetings Manu
Best,
Stjepan