Hi Oliver, On Thu, Mar 13, 2008 at 12:31 AM, Kowalke Oliver (QD IT PA AS) <Oliver.Kowalke@qimonda.com> 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/example...), 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