Re: Re: ipc.pdf ... some remarks

Herman Bruyninckx wrote:

> > Look at my document where I describe my events. All consumers activate the
> > event with their parameters. As soon as you have new data at the producer
> > (you have read the battery voltage) you check all your activations and
> > decide depending on the individual parameters whether to fire or not.
>
> But _what_ do you fire? An event that carries the data that caused the
> event? In that case you notify too many clients. I fail to see how
> sending the data along and let the consumer decide _after_ the facts,
> is better than letting the consumers decide _at registration time_
> what events they want to get.

The design document contains a detailed description of the events. Several
activations result in individual events with individual event parameters. When
the producer decides (depending on the parameters and the current data) to fire
an activated event, only that activation gets notified. The object send back
with the event notification can be augmented with several other information
which might be relevant for the consumer to further interpret an event and to
react. The consumer never decides whether to fire or not, it only sets the
parameters for the method of the producer which checks whether to fire or not.


> This, in my view, belongs to the device component guarding the
> battery, not to its event object.

Again wording is difficult. If the event object is the object which is
transmitted between producer and consumer when the event fires then the event
object is exactly the object described above which can be augmented with
additional information reporting on details which caused the event to fire. The
decision to fire already happened when the event object is sent by the event
pattern. The producer event pattern takes (in the battery monitoring component)
the battery voltage, internally checks the event condition based on that battery
voltage with all the parameters from the activations and decides which
activation fires. Firing is done by generating the event object and transmitting
it to that consumer part of the event pattern which activated that parameters
(all other activations are not influenced).

> > Therefore: battery component provides an event which takes parameters on
> > the voltage level and wether I want to be informed in case of falling below
> > or getting above or both etc.
>
> I would send the former data also, but not the latter decision information.
> This decision must be made by the consumer, at registration time.
>
> > (see my remarks on different kinds of event,
> > with state and without state: corresponds to state versus edge triggered).
>
> This is an interesting discussion in itself: where do we need edge
> triggering and where level triggering...? Or rather, where do we have
> to export this information?
>
> > If consumer A activates the event with "below 10%" it gets his activation
> > fired as soon as his event condition is true. The producer only puts in the
> > battery voltage and the producer part of the event does everything else.
> > The implementer of the battery event simply provides the method for the
> > condition check.
>
> I have the impression that you have to evaluate the condition twice:
> once in the battery component (otherwise, it will not generate an
> event), and once in the event handler?

No, the event handler at the consumer side is the asynchronous interface (you
also have a blocking wait etc.) to handle an arriving event object. As soon as
you get the event object you know that the condition has been fulfilled because
otherwise your activation would not have fired.


Christian



>
>
> Herman
>
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------