I noticed that when using timed actions like the ones generated by pnpgen_linear with goto_foo|5 when the wait_5 is over, goto_foo is interrupted. The way this is currently implemented is that interrupt means interrupted and not cancelled so in theory the action could be resumed. This leads to the strange behaviour that the action goto_foo is still in the activeExecutables in pnp_plan.hpp.Hence, when the goal state is reached, the activeExecutables are cleaned up once the goal state is reached. Therefore I get something like this:
So even though it was interrupted and the goal state was reached, the end() function was still triggered. This can easily be bypassed by just changing this line from
if (v[1] == "end" || v[1] == "fail") {
#if DELETE_CONCLUDED_EXECUTABLES
PNP_OUT("******* I can destroy '"<<v[0]<<"'");
activeExecutables.erase(v[0]);
delete a;
#else
PNP_OUT("******* I won't destroy '"<<v[0]<<"'");
inactiveExecutables.insert(make_pair(v[0], a));
activeExecutables.erase(v[0]);
#endif
}
to
if (v[1] == "end" || v[1] == "fail" || v[1] == "interrupt") {
#if DELETE_CONCLUDED_EXECUTABLES
PNP_OUT("******* I can destroy '"<<v[0]<<"'");
activeExecutables.erase(v[0]);
delete a;
#else
PNP_OUT("******* I won't destroy '"<<v[0]<<"'");
inactiveExecutables.insert(make_pair(v[0], a));
activeExecutables.erase(v[0]);
#endif
}
but that means that the actions could not be resumed any more. In general I think that interrupt is not the right function for timed actions. One could argue to change it to fail but imho that would be ambiguous because it could also fail due to the action not being executable. I guess that would be major changes but implementing something like cancel would be most approriated for timed actions. This should, like end and fail set the executable to inactive whereas interrupt would keep it as active in case it was supposed to be resumed.
All this ending a process after the plan has finished might not be too big of an issue but I think that conceptually it is wrong to use interrupt for timed actions given the way it is implemented now.
Also, I discovered a problem with the allocation of IDs that might lead to a problem due to the fact that these actions are kept active. I will describe that in a separate issue.
Hi,
I noticed that when using timed actions like the ones generated by pnpgen_linear with
goto_foo|5when thewait_5is over,goto_foois interrupted. The way this is currently implemented is that interrupt means interrupted and not cancelled so in theory the action could be resumed. This leads to the strange behaviour that the actiongoto_foois still in theactiveExecutablesinpnp_plan.hpp.Hence, when the goal state is reached, theactiveExecutablesare cleaned up once the goal state is reached. Therefore I get something like this:So even though it was interrupted and the goal state was reached, the
end()function was still triggered. This can easily be bypassed by just changing this line fromto
but that means that the actions could not be resumed any more. In general I think that interrupt is not the right function for timed actions. One could argue to change it to fail but imho that would be ambiguous because it could also fail due to the action not being executable. I guess that would be major changes but implementing something like
cancelwould be most approriated for timed actions. This should, likeendandfailset the executable to inactive whereasinterruptwould keep it as active in case it was supposed to be resumed.All this ending a process after the plan has finished might not be too big of an issue but I think that conceptually it is wrong to use interrupt for timed actions given the way it is implemented now.
Also, I discovered a problem with the allocation of IDs that might lead to a problem due to the fact that these actions are kept active. I will describe that in a separate issue.