The-OpenROAD-Project
ctrl-c doesn't always work when GUI is launched from a batch script or other app
Description
Stripping down my use-case, launch the GUI from a script, and to illustrate that ctrl-c is not propagated properly anymore: the GUI is still running after I ctrl-c the script that launches the GUI.
make "$@" &
wait
$ ./foo.sh gui_grt
gui::update_timing_report
^C[WARNING UTL-0014] OpenROAD will terminate after the next control+C
$
The GUI is still running here, and if I hit ctrl-c again, that doesn't reach the GUI so I have to close/kill it by other means.
Suggested Solution
Not sure. Add option to openroad to disable ctrl-c behavior?
Additional Context
This breaks for instance the bazel-orfs use-case:
bazel run Foo_floorplan /tmp/foo gui_floorplan
The option to disable it is -exit, is that missing? I have no way to run this test case, I can take a look if you upload a test case that is runnable.
It doesn't make sense to have ctrl-c abort the GUI on the first time as that is used for cancelable commands.
It doesn't make sense to have ctrl-c abort the GUI on the first time as that is used for cancelable commands.
For cases where openroad is a subprocess and this feature is not used or worth the complication in signal handling or surprises in behavior, it would be nice to be able to disable openroad's amended ctrl-c behavior to support cancelable operations via ctrl-c.
there are other examples where ctrl-c is overridden, from python scripts to user interfaces(ps, vi, etc.), but this does come with surprises and complications sometimes.