|
Boost Users : |
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-08-25 14:40:30
On Sun, Aug 24, 2008 at 11:51 AM, Manuel Jung <gzahl_at_[hidden]> wrote:
>>
>> 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.
>
> I think, i would prefer something more like the second approach, where the
> operators are altered. I have this in mind:
> You should just be able to user another type of conenction of components, an
> async typ, which uses a threadpool. This way you are still able to connect
> components the normal way so they get executed in one row (would be useful
> e.g. when the components are rather fast executed)
>
OK, I thought about this some... Unfortunately, the Dataflow library
has some fundamental limitations when it comes to creating connections
(you can't provide a parameter for the connection, e.g., to specify
that it should be immediate vs. using a threadpool), so the only way
to change the type of the connection is to change the type of the
components being connected. This will make it harder to implement the
second approach, which aims to leave the components in tact.
Here are some examples that implement new connection types allowing
consumers to track their producers:
http://svn.boost.org/svn/boost/sandbox/SOC/2007/signals/libs/dataflow/example/signals/specific_tracking_consumer_example.cpp
http://svn.boost.org/svn/boost/sandbox/SOC/2007/signals/libs/dataflow/example/signals/tracking_consumer_example.cpp
>
> 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.
Kind regards,
Stjepan
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net