Closed duylethanh closed 2 years ago
I think we should integrate the signal handler into our event loop. This makes sure that all the code runs synchronously, without any surprises (e.g., we do not need to care when the signal handler runs).
We can do this by using the Python function set_wakeup_fd
: create a pipe (os.pipe()
), set the writer side as the wakeup FD, add the reader side to our selector
. When the pipe becomes readable, read the signal number and terminate the process.
PR updated.
I added missing os.close()
calls on the pipes.
PR ready for review.
PR updated
PR updated and ready for review
Ah, now I understand why we exit the program. But I still think the code would be cleaner if we let the event loops finish as usual (and clean up everything properly even in the exit path); afterwards, we can throw an exception to exit the whole program (instead of doing sys.exit
). That way, higher level code can decide if it wants to exit or continue with the next run or so.
Ah, now I understand why we exit the program. But I still think the code would be cleaner if we let the event loops finish as usual (and clean up everything properly even in the exit path); afterwards, we can throw an exception to exit the whole program (instead of doing
sys.exit
). That way, higher level code can decide if it wants to exit or continue with the next run or so.
Instead of sys.exit()
we now raise the following error.
raise RuntimeError(
"simexpal received a termination signal (either SIGINT or SIGTERM) and has terminated "
"the current child process")
This PR contains the following:
If
SIGINT
(CTRL + C) orSIGTERM
is caught, kill running child processes before terminating. Note that we can not handleSIGKILL
this way.