Open brice-morin opened 6 years ago
I definitely think that there should be a way to do a graceful termination - but whether we should add an on terminate
concept or use the existing on exit
concept, I'm not completely sure. My feeling is that if we add on terminate
, we would probably write the same code in both on exit
and on terminate
to e.g. close files IOs in both cases, which would be a bit annoying...
If we decide that on exit
should be called when the program shuts down - then the expected output in the tests should be updated to include any output characters that will be printed. That shouldn't be too difficult :grin:. Further - as you point out - we might need to update the Posix compiler to handle that as well.
Is how we execute ThingML programs, it currently seems to differ a bit between the compilers. Some keep going indefinitely until they are killed (Posix + Java), while others terminate when there is "nothing to do" (NodeJS). IMHO they should keep running until they are intentionally stopped - which seems easier to implement as well.
However, if we choose to go that route (which we have kind of started), we have the problem that there is currently no consistent way of stopping a ThingML program from within. I think something is supposed to happen with final state
s - but I'm not quite sure how that works - but I also think that there should be a way to stop execution when errors occur (i.e. quitting with a exit code != 0).
Maybe we could automatically terminate the programs if all instances/sessions/regions/... are currently in a final state
- but also add an exit <code>
statement that could be used?
It would definitely be useful in the tests!
There is already a catch mechanism for SIGTERM and SIGINT in the PosixMT compiler, but it doesn't call the on exit
of any thing.
void term(int signum)
{
fflush(stdout);
fflush(stderr);
exit(signum);
}
int main(int argc, char *argv[]) {
struct sigaction action;
memset(&action, 0, sizeof(struct sigaction));
action.sa_handler = term;
sigaction(SIGINT, &action, NULL);
sigaction(SIGTERM, &action, NULL);
/*C_MAIN*/
/*INIT_CODE*/
/*POLL_CODE*/
}
In Java, when the process is being terminated (e.g. on SIG-TERM), we strive to shutdown gracefully by calling
on exit
on the root composite state (which callson exit
from the inner-most state up to the root). The idea behind that is that some states might have open some I/Os, etc that we might want to close properly before exiting.The problem is that the tests kill the generated Java programs, which execute this extra
on exit
behavior that is not expected, and which typically adds some traces to the test outputs, which are not expected neither, making the test to fail.So, I see two alternatives:
I am not too in favor of 2., as I think this termination behavior might be wise, but it is of course quite easy to de-activate. We might also want to add some
on terminate
concepts in ThingML?Any comment?