Issue 10492: Component can't reset another component (rtc-ftf) Source: Real-Time Innovations (Mr. Rick Warren, rwarren@rti.com rick.warren@rti.com rick@rti.com) Nature: Uncategorized Issue Severity: Summary: Source: RTI (Rick Warren, [[MailTo(rick DOT warren AT SPAMFREE rti DOT com)]]) Severity: Minor Disposition: Resolution Proposed Summary The message to reset a component will usually come from another component. If a component resets itself, it can know which context has the error, so there is no problem. But if a different component wants to reset it, there is no way for it to know which context is the correct one. Discussion Resolution I think we can solve this problem with a new method: ExecutionContext[] LifeCycle::get_contexts() The code would look something like this: ExecutionContext[] contexts = myComponent.get_contexts(); //... if (contexts[i].get_component_state(myComponent) == ERROR_STATE) { myComponent.reset(contexts[i]); } The usage is demonstrated in the following sequence diagram (which also shows a proposed move of the reset() operation from the component itself to the execution context -- thanks, Sakamoto-san): [attachment:rtc-reset-sequence.png] -- RickWarren, 2006/12/1 Revised Text Resolution: It is already possible to determine the state of a component in a given context with the ExecutionContextOperations::get_component_state operation. Therefore, the only functionality that is missing is the ability to learn in which context(s) a component participates and which context is associated with which handle. Add operations to provide that information. The existing method RTObject::get_execution_context_services provides a subset of the functionality proposed here. It should be replaced with a more complete functionality. Revised Text: · Add operations to LightweightRObject: · Add the following rows to the Operations table in section 7.2.2.2, LightweightRTObject: get_owned_contexts ExecutionContextOperations[] get_participating_contexts ExecutionContextOperations[] get_context_handle ExecutionContextHandle_t context ExecutionContext · Add the following subsections to the end of section 7.2.2.2, LightweightRTObject: 7.2.2.2.8 get_owned_contextsDescriptionThis operation returns a list of all execution contexts owned by this RTC.7.2.2.2.9 get_participating_contextsDescriptionThis operation returns a list of all execution contexts in which this RTC participates.SemanticsEach call to attach_context causes the provided context to be added to this list. Each call to detach_context causes the provided context to be removed from this list.7.2.2.2.10 get_context_handleDescriptionThis operation returns a handle that is associated with the given execution context.SemanticsThe handle returned bt this operation is same as the handle returned by attach_context. · Add the above operations to Figure 7.3, Lightweight RTC M1 Illustration. (The following figure is also modified by the resolution to issue 10492.) Figure 7.3 - Lightweight RTC M1 Illustration · Add the following to the IDL in RTC.idl and Annex A: typedef sequence<ExecutionContext> ExecutionContextList; interface LightweightRTObject : ComponentAction { // … ExecutionContextList get_owned_contexts (); ExecutionContextList get_participating_contexts (); ExecutionContextHandle_t get_context_handle ( in ExecutionContext context); // … activate_component and other operations }; · Add a sequence diagram illustrating how a RTC can be reset. In section 7.2.2.6.10, reset_component (introduced by the resolution to issue 10490), the Semantics subsection has two paragraphs. Add the following diagram in between them: Figure <number> - ExecutionContextOperations::reset_component · Remove RTObject::get_execution_context_services: it is obsolete. · Remove the operation from figure 7.22, Introspection overview, at the beginning of section 7.4, Introspection. · Remove the operation from figure 7.24, Introspection interfaces, at the beginning of section 7.4.2, Stereotypes and Interfaces. · Remove the corresponding row from the operations table in section 7.4.2.2, RTObject. · Remove section 7.4.2.2.3, get_execution_context_services. · Remove the operation's declaration from the IDL definition of RTObject in RTC.idl and in Annex A of the specification. · Remove ExecutionContextService::add() and remove() from Annex A and from RTC.idl. (These operations were removed from the PIM by issue 10496, but were accidentally not removed from the PSM.) · Specify that the execution contexts provided for an introspective component should be of type ExecutionContextService. Add the following to section 7.4.2.2, RTObject, just above the Operations subsection: Constraints· Any execution contexts returned from the inherited methods LightweightRTObject::get_owned_contexts and LightweightRTObject::get_participating_contexts shall be of type ExecutionContextService. Actions taken: December 5, 2006: received issue January 15, 2008: closed issue Discussion: End of Annotations:===== MG issue 10492: Component can't reset another component Source: RTI (Rick Warren, [[MailTo(rick DOT warren AT SPAMFREE rti DOT com)]]) Severity: Minor Disposition: Resolution Proposed Summary The message to reset a component will usually come from another component. If a component resets itself, it can know which context has the error, so there is no problem. But if a different component wants to reset it, there is no way for it to know which context is the correct one. Discussion Resolution I think we can solve this problem with a new method: ExecutionContext[] LifeCycle::get_contexts() The code would look something like this: ExecutionContext[] contexts = myComponent.get_contexts(); //... if (contexts[i].get_component_state(myComponent) == ERROR_STATE) { myComponent.reset(contexts[i]); } The usage is demonstrated in the following sequence diagram (which also shows a proposed move of the reset() operation from the component itself to the execution context -- thanks, Sakamoto-san): [attachment:rtc-reset-sequence.png] -- RickWarren, 2006/12/1 Revised Text