[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Event requests precedence
|
One thing to not forget, the experiment knows about its traces, but the
traces don't known about the experiment they are part of. To coalesce a
request that is sent by a trace with a request from the experiment the
trace has to know about the experiment.
With the patches the logic is encapsulated in the TmfEventProvider class
and in the TmfCoalescedEventRequest class Also, it takes care of that an
event from an coalesced request is only dispatched to traces that were
interested in that event from that trace. This used to be different back
in the days, where each trace request had to filter out unwanted events
from another trace from the experiment.
For the developer point of view, the changes are quite transparent and
the developer doesn't have to know about the new component interface.
The TmfEventProvider class takes care of it. Of course, if a developer
implement ITmfEventProvider and other relevant interfaces themselves
(and not extending TmfTrace, TmfEventProvider etc) then he would have to
take care the new interface. This, I agree, would be not straight
forward and is not recommended (as for many other reasons).
These patch set will also allow the case were experiments contain other
experiments which Genevieve mentioned once that she would need at one point.
When implementing these patches I also explored quickly the suggestion
to have a separate event request manager that will coalesce requests
from different sources (trace, experiment, analyses etc). However, these
request manager would need to know insights of the trace, experiment and
event provider classes which would need to be exposed. Right now these
things are encapsulated and it seems to me the better way to go to keep
it like that.
Best Regards
Bernd
On 11/05/2014 11:55 PM, Alexandre Montplaisir wrote:
Just a note, in my previous message I talk about a "request manager",
this seems to be actually part of the TmfCoalescedEventRequest class.
On 11/06/2014 02:54 AM, Alexandre Montplaisir wrote:
On 11/05/2014 05:45 PM, Geneviève Bastien wrote:
Why were those patches not merged? Was there any other issue of
discussion beyond no performance improvement?
IIRC, both *you* and me didn't really like the approach 100%, which
is why they weren't merged in the end ;)
It introduced a new interface, ITmfCompositeComponent, which pushed
to the components the responsibility of defining their
parent/children relationships. In the case of experiments for
example, these relationships can be inferred by looking the
experiment and its getTraces(). Which, imo, made the new
CompositeComponent interface redundant.
I/we would have preferred an approach where those relationships could
be discovered "automatically" by the request manager, and that it
could send events to the components in the correct order. Pushing the
responsibility to the component is 1) more work for the devs every
time they define a new component, 2) more chances to make mistakes.
I mentioned priorities earlier, but now I realize it's not that much
better, since it's still something that components have to define
themselves ("put me before/after this other component").
Wouldn't it be possible for the request manager to determine these
priorities whenever a request gets coalesced among multiple
components? For experiments, you can look at its child traces. For
analysis modules, you can look at which modules are dependant on it.
You'd just have to be careful about not resolving this order for
every event, it just has to be done once, at the start of the
coalesced request, then the events get sent to the relevant
components in the correct order.
Thoughts?
Cheers,
Alex
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
