Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run gz sim on Windows #2393

Open
traversaro opened this issue May 2, 2024 · 8 comments
Open

Run gz sim on Windows #2393

traversaro opened this issue May 2, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@traversaro
Copy link
Contributor

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 #2089 is fixed, that should happen once #2382 is merged (this depends on a new gz-rendering release).

I opened a separate issue as #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.

@traversaro traversaro added the enhancement New feature or request label May 2, 2024
@traversaro
Copy link
Contributor Author

traversaro commented May 2, 2024

I tried to quickly solve this in #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 gazebosim/gz-tools#7 for gz sim.

@mjcarroll the last PR on the topic seems #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).

@azeey azeey moved this from Inbox to In progress in Core development May 6, 2024
@traversaro
Copy link
Contributor Author

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).

Actually we can use gazebosim/gz-utils#98, hopefully subprocess.h is able to handle well Ctrl+C on Windows.

@traversaro
Copy link
Contributor Author

Actually we can use gazebosim/gz-utils#98, hopefully subprocess.h is able to handle well Ctrl+C on Windows.

This seems related: gazebosim/gz-utils#127, and I am afraid it is hitting all the problems that I was encountering with propagating Ctrl+C on Windows in Ruby.

@mjcarroll
Copy link
Contributor

Signal handling and propagation on Windows is incredibly dumb. I honestly think finishing up standalone executables is the better approach.

@traversaro
Copy link
Contributor Author

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).

@mjcarroll
Copy link
Contributor

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.

@traversaro
Copy link
Contributor Author

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.

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.

@johnwason
Copy link

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.

(I am using Gazebo 11 on Windows so I need a replacement if it is going EOL.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In progress
Development

No branches or pull requests

3 participants