Issue 10491: Inconsistent definition of ComponentAction callbacks                                                                                                                                                    (rtc-ftf)
Source: Technologic Arts (Mr. Takeshi Sakamoto, tsakamoto@tech-arts.co.jp)
Nature: Uncategorized Issue
Severity: 
Summary: Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

Which is correct as for the on_aborting and on_reset callbacks on ComponentAction?

on_aborting(ExecutionContext) : void

Figure 7.2 (Page 11)

on_aborting(ExecutionContext) : ReturnCode_t

Table (Page 19) and RTC IDL (Page 76) and mars/2006-09-34 (Example C++ header)

on_reset(ExecutionContext) : void

Figure 7.2 (Page 11)

on_reset(ExecutionContext) : ReturnCode_t

Table (Page 19) and RTC IDL (Page76) and mars/2006-09-34 (Example C++ header)

Discussion

Is it useful for on_aborting to return an error if the component is already transitioning to an error state? I suppose the middleware implementation could log it.... -- RickWarren, 2006/11/27

Resolution

I would propose that all callbacks, including on_aborting and on_error, should return ReturnCode_t instead of void to be consistent. The middleware implementation may choose to log the error or do something else; no particular behavior is required. -- RickWarren, 2006/12/1

Do you mean that activate_component only returns the result of on_activate, and for example on_aborting does not relate with activate_component operation call? The specification has the following three sets of events and callbacks.

    *

      activate_component event only assumes that on_activate has finished before it returns.
    *

      deactivate_component event only assumes that on_deactivate has finished before it returns.
    *

      reset_component event only assumes that on_reset has finished before it returns. (If reset_component operation in FTF-12 is adopted.) 

If so, I agree the above Rick's proposal. I think that the more details beyond it should be left as implementation-defined matter.

-- NoriakiAndo, 2006/12/4

Revised Text
Resolution: The return types of the ComponentAction callbacks are addressed in issue 10477, which updates the figure in question, Figure 7.2. With respect to that matter, this issue shall be considered a duplicate.
The remainder of this issue is addressed as follows:
·	activate_component assumes that on_activate has finished before it returns.
·	deactivate_component assumes that on_deactivate has finished before it returns.
·	reset_component assumes that on_reset has finished before it returns.
·	Remove extra arguments from on_transition and on_mode_changed

Revised Text: ·	The following text should be added immediately before Constraints in section 7.2.2.6.6, activate_component:
SemanticsThe callback on_activate shall be called as a result of calling this operation. This operation shall not return until the callback has returned, and shall result in an error if the callback does.
·	The following text should be added immediately before Constraints in section 7.2.2.6.7, deactivate_component:
SemanticsThe callback on_deactivate shall be called as a result of calling this operation. This operation shall not return until the callback has returned, and shall result in an error if the callback does.
·	In the adjacent section reset_component (moved under 7.2.2.6 by issue 10490), the first sentence under Semantics reads: "The ComponentAction::on_reset callback shall be invoked." This sentence should be followed by this new sentence:
This operation shall not return until the callback has returned, and shall result in an error if the callback does.
·	In the definition of the FsmComponentAction interface in RTC.idl and in Annex A, remove the argument "in LightweightRTObject comp" from the on_transition method.
·	In the definition of the MultiModeComponentAction interface in RTC.idl and in Annex A, remove the argument "in LightweightRTObject comp" from the on_mode_changed method.

Actions taken:
December 5, 2006: received issue
January 15, 2008: closed issue
Discussion: 

End of Annotations:=====
MG issue 10491: Inconsistent definition of ComponentAction callbacks

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

Which is correct as for the on_aborting and on_reset callbacks on ComponentAction?

on_aborting(ExecutionContext) : void

Figure 7.2 (Page 11)

on_aborting(ExecutionContext) : ReturnCode_t

Table (Page 19) and RTC IDL (Page 76) and mars/2006-09-34 (Example C++ header)

on_reset(ExecutionContext) : void

Figure 7.2 (Page 11)

on_reset(ExecutionContext) : ReturnCode_t

Table (Page 19) and RTC IDL (Page76) and mars/2006-09-34 (Example C++ header)

Discussion

Is it useful for on_aborting to return an error if the component is already transitioning to an error state? I suppose the middleware implementation could log it.... -- RickWarren, 2006/11/27

Resolution

I would propose that all callbacks, including on_aborting and on_error, should return ReturnCode_t instead of void to be consistent. The middleware implementation may choose to log the error or do something else; no particular behavior is required. -- RickWarren, 2006/12/1

Do you mean that activate_component only returns the result of on_activate, and for example on_aborting does not relate with activate_component operation call? The specification has the following three sets of events and callbacks.

    *

      activate_component event only assumes that on_activate has finished before it returns.
    *

      deactivate_component event only assumes that on_deactivate has finished before it returns.
    *

      reset_component event only assumes that on_reset has finished before it returns. (If reset_component operation in FTF-12 is adopted.) 

If so, I agree the above Rick's proposal. I think that the more details beyond it should be left as implementation-defined matter.

-- NoriakiAndo, 2006/12/4

Revised Text