Fisrt, the current hardcoded behaviour of stop() (hardcoded timeout) is
obviously very fragile on a lot of applications, and makes error
handling problematic.
Since I do need to handle errors properly in our execution layer, I
would like to make sure that I understand the logic properly.
AFAIK, there are three failure modes when stopping a component:
- the updateHook actually does not return. stop() will return false
and the update -> stop state update will never happen
- the updateHook did not return in the hardcoded allocated time (1s
for non-periodic tasks), but will. stop() will return false, but the
running -> stop state transition will happen.
- stopHook raised. I don't know what stop() will return there, but at
least a running -> fatal_error state transition should happen
Am I right ?
Failure modes of stop()
On Fri, May 4, 2012 at 4:46 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> Fisrt, the current hardcoded behaviour of stop() (hardcoded timeout) is
> obviously very fragile on a lot of applications, and makes error
> handling problematic.
Ack.
>
> Since I do need to handle errors properly in our execution layer, I
> would like to make sure that I understand the logic properly.
>
> AFAIK, there are three failure modes when stopping a component:
>
> - the updateHook actually does not return. stop() will return false
> and the update -> stop state update will never happen
this is the case if breakUpdateHook() returned false.
> - the updateHook did not return in the hardcoded allocated time (1s
> for non-periodic tasks), but will. stop() will return false, but the
> running -> stop state transition will happen.
I don't think this case exists. It just remains running afaikt.
> - stopHook raised. I don't know what stop() will return there, but at
> least a running -> fatal_error state transition should happen
It will return false and the transition is made to the exception
state, not fatal_error.
- not in Running state, stop() will also return false.
The major issue in current software is the hardcoded 'wait times' for
update hook to return. We once worked around that by setting a long
period with setPeriod and then doing a stop()... It should be possible
to specify a wait condition (time or something else)
Peter
>
> Am I right ?
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Failure modes of stop()
On 05/04/2012 05:05 PM, Peter Soetens wrote:
>> Since I do need to handle errors properly in our execution layer, I
>> would like to make sure that I understand the logic properly.
>>
>> AFAIK, there are three failure modes when stopping a component:
>>
>> - the updateHook actually does not return. stop() will return false
>> and the update -> stop state update will never happen
>
> this is the case if breakUpdateHook() returned false.
Ah ... Fault from my side
I only consider *failure* cases, i.e. cases where
breakUpdateHook/breakLoop do return true but something weirdo happens.
>
>> - the updateHook did not return in the hardcoded allocated time (1s
>> for non-periodic tasks), but will. stop() will return false, but the
>> running -> stop state transition will happen.
>
> I don't think this case exists. It just remains running afaikt.
The thread implementation warns "breakLoop returned true but did not
return in XXX seconds" and stop returns false. Since breakLoop got
called, is it not possible that the activity *does* break the loop next
time the updateHook returns (assuming that it blocks because of the
updateHook) and then never gets called again ?
>> - stopHook raised. I don't know what stop() will return there, but at
>> least a running -> fatal_error state transition should happen
>
> It will return false and the transition is made to the exception
> state, not fatal_error.
I was expecting the other way. From our previous discussions, the idea
was that we assumed that a successful stopHook would put the component
back in a "known" state, but failure to do so removes any possibility of
recovery.
> - not in Running state, stop() will also return false.
Ah... Yes ;-)
> The major issue in current software is the hardcoded 'wait times' for
> update hook to return. We once worked around that by setting a long
> period with setPeriod and then doing a stop()... It should be possible
> to specify a wait condition (time or something else)
What I am personally leaning towards is a way to completely disable
this. The upper layers should, in our case, very well handle a blocking
updateHook so I really don't want to have RTT arbitrarily decide on
this. Obviously, this is useful for "script with human looking at it"
kind of cases, so both behaviours are needed.
The question is how to propagate that configuration parameter.
Deployment-time configuration ? Environment variable ?