gz-sim
gz-sim copied to clipboard
Run `gz sim` on Windows
Desired behavior
I would like gz sim to work on native Windows, so that all the existing tutorials apply also on native Windows.
Alternatives considered
Manually run gz sim -s and gz sim -g on separate terminals forever.
Implementation suggestion
See rest of discussion.
Additional context
This is the next steps once https://github.com/gazebosim/gz-sim/issues/2089 is fixed, that should happen once https://github.com/gazebosim/gz-sim/pull/2382 is merged (this depends on a new gz-rendering release).
I opened a separate issue as https://github.com/gazebosim/gz-sim/issues/168 is more broad and covers a lot of Windows support (including fixing all the test suite) while this one covers only running gz sim on Windows.
I tried to quickly solve this in https://github.com/gazebosim/gz-sim/pull/2392, but it turned out to be quite complex to handle correctly the process shutdown, due to intrinsic complexity of Windows signal system and how it is wrapper in Ruby's APIs. Related links: https://blog.simplificator.com/2016/01/18/how-to-kill-processes-on-windows-using-ruby/, https://bugs.ruby-lang.org/issues/17820, https://learn.microsoft.com/en-us/windows/console/generateconsolectrlevent, CREATE_NEW_PROCESS_GROUP flag in https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa .
While I can try to tackle the problem, I wonder if the time may be spent better by working in solving https://github.com/gazebosim/gz-tools/issues/7 for gz sim.
@mjcarroll the last PR on the topic seems https://github.com/gazebosim/gz-sim/pull/694, could it make sense to try to update that PR or there have been relevant update on the topic? Thanks!
Note that to handle easily the routing of Ctrl+C events to the server and/or gui processes, it may be convenient to use a third party library such as tiny-process-library (https://gitlab.com/eidheim/tiny-process-library, used in Gazebo Classic) or reproc (https://github.com/DaanDeMeyer/reproc).
Note that to handle easily the routing of Ctrl+C events to the server and/or gui processes, it may be convenient to use a third party library such as
tiny-process-library(https://gitlab.com/eidheim/tiny-process-library, used in Gazebo Classic) orreproc(https://github.com/DaanDeMeyer/reproc).
Actually we can use https://github.com/gazebosim/gz-utils/pull/98, hopefully subprocess.h is able to handle well Ctrl+C on Windows.
Actually we can use gazebosim/gz-utils#98, hopefully
subprocess.his able to handle well Ctrl+C on Windows.
This seems related: https://github.com/gazebosim/gz-utils/pull/127, and I am afraid it is hitting all the problems that I was encountering with propagating Ctrl+C on Windows in Ruby.
Signal handling and propagation on Windows is incredibly dumb. I honestly think finishing up standalone executables is the better approach.
Signal handling and propagation on Windows is incredibly dumb. I honestly think finishing up standalone executables is the better approach.
I totally agree, the problem that also in that case we need to have the gz-sim executable that should be able to propagate the Ctrl+C to gz-sim-server and gz-sim-gui (unless we go for a single process for server and gui, but I am not sure if it is doable). On Gazebo Classic that is handled by https://gitlab.com/eidheim/tiny-process-library in https://github.com/gazebosim/gazebo-classic/blob/e4b4d0fb752c7e43e34ab97d0e01a2a3eaca1ed4/gazebo/gazebo_main.cc#L290, that is doing something quite specific I guess (see https://gitlab.com/eidheim/tiny-process-library/-/blob/v2.0.4/process_win.cpp?ref_type=tags#L297 and http://stackoverflow.com/a/1173396).
I think that tiny_process_library also uses ProcessTerminate, which is the equivalent of sigkill on Windows. That will certainly stop the process, but it's not necessarily a clean way of doing it. In my PR that you referenced above (gazebosim/gz-utils#127) I was trying to see if we could send something closer to a ctrl+c or ctrl+break on Windows to allow for a cleaner shutdown of processes.
I think that tiny_process_library also uses
ProcessTerminate, which is the equivalent ofsigkillon Windows. That will certainly stop the process, but it's not necessarily a clean way of doing it.
I am not sure about that, I never encountered zombie process on Gazebo Classic on Windows, but indeed I did not explicitly checked what is going on.
I created a package called drekar-launch that correctly uses Windows messages to terminate processes. There are small companion packages drekar-launch-process and 'drekar-launch-process-cppthat receive either Unix signals or Windows messages to terminate.drekar-launch` uses Jinja2 templates so I think you can implement the logic you have in Ruby using this package instead.
drekar-launch-process-cpp is in vcpkg and my conda channel (I can submit to conda-forge easily) so it should not be a difficult dependency to add. drekar-launch is a simple Python package that does not require more than a standard Python environment to run.
- https://github.com/johnwason/drekar-launch
- https://github.com/johnwason/drekar-launch-process
- https://github.com/johnwason/drekar-launch-process-cpp
(I am using Gazebo 11 on Windows so I need a replacement if it is going EOL.)