TelluIoT / ThingML

The ThingML modelling language
https://github.com/TelluIoT/ThingML
Apache License 2.0
101 stars 32 forks source link

Behavior on SIG-TERM #191

Open brice-morin opened 6 years ago

brice-morin commented 6 years ago

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 calls on 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:

  1. Updating the test oracles so that they accept this termination behavior
  2. Removing this termination behavior (I think only Java, and maybe JS implement it).

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?

jakhog commented 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.

Another slightly related issue

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 states - 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!

nharrand commented 6 years ago

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.

Here

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*/
}