RTC — 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

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