Re: [boost] Review Request: Dataflow.Signals

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-03-13 04:00:11

Hi Oliver,

On Thu, Mar 13, 2008 at 12:31 AM, Kowalke Oliver (QD IT PA AS)
<Oliver.Kowalke_at_[hidden]> wrote:
> Hi,
>  I've some questions related to Dataflow.Signals library:
>
>  - As mentioned in the docs the library models the pipe-filter pattern. What about event handling? The arguments of the function calls could be seen as the payload of the event?!
>

Right - if the signal is used to model an event, any information
associated with the event can be passed as an argument.
Alternatively, if there is no information except for the event itself,
you can use a signal of signature `void()`.

E.g., in the GIL example
(http://dancinghacker.com/code/dataflow/dataflow/signals/introduction/examples/gil.html),
the output of the `timer` component is analogous to an event (timer
cycle) with no extra information (hence uses the `void()` signature).
When `generator` receives the event, it sends out an image, etc..
There is nothing in the library that distinguishes between signals
used for events and signals used for data - it's just how it's used.

I'm not sure if I answered this question adequately, please let me
know if I didn't.

>  - Is it possible that one consumer instance is connected to multiple producers?
>

Yes.  But, when a consumer receives the data, it has no knowledge of
where it came from.  If you need that information, you can make it a
part of the signal.

>  - Can a consumer decide if it will disconnect form its producer inside the invoked operator()-function?
>

You mean, when the consumer receives a signal, you'd like it to be
able to disconnect from the producer that sent the signal?  There
isn't anything in the library that directly supports this, and an
additional difficulty is that the consumer has no knowledge of any of
the connected producers by default.

There would have to some outside mechanism that would allow this - one
way would be to return something to the producer that would tell it to
disconnect that particular consumer.  Another would be to have the
consumer keep a copy of the Boost.Signals connection object (for the
connection between its producer and itself), and disconnect at will.
A third strategy would be to send a signal/function call to some
network-managing component that would perform the disconnect.  I have
some unfinished business with the disconnection code - if you're
interested in any of these strategies let me know and I'll implement
what is necessary to make it doable and produce an example.

Thanks for your interest in the library!

Stjepan