-
Notifications
You must be signed in to change notification settings - Fork 34
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
unnecessarily uses a loop to wait for steam-runtime-launcher-service #231
Comments
Do not use a loop to sleep until the Steam Runtime launcher has finished starting up. Instead, wait until the Steam Runtime launcher produces stdout on initial startup. After this every subsequent `wine_launch.sh` invocation can assume the launcher is up instead of checking for the socket in a loop. This approach was suggested by @smcv on GitHub. Fixes #231
Thanks for looking at this! 58bb325 will probably work in practice (because the launcher service doesn't output very much text, so the pipe buffer will not be full), but the intended use of In Python, If you stop reading after the first byte, the launcher service could get stuck (blocked in The unit tests in https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/tests/pressure-vessel/launcher.py include some tests that use the |
The
|
Hmm, thanks. That shouldn't be the case - I'll look at that when I get a chance. I would guess that some other process in the hierarchy is keeping stdout open. |
Ah, I think I see why that happens - it's probably because either (FYI, Until then, you could try something like this (untested):
|
Do not use a loop to sleep until the Steam Runtime launcher has finished starting up. Instead, create a pipe and pass it to the underlying `steam-runtime-launcher-service` executable; the executable will write to it and close it to indicate the launcher has finished starting up. After this every subsequent `wine_launch.sh` invocation can assume the launcher is up instead of checking for the socket in a loop. This approach was suggested by @smcv on GitHub. Fixes #231
Thank you, the suggested solution works as intended and I've pushed it to master. |
This was ValveSoftware/steam-runtime#593 and I fixed it in pressure-vessel 0.20230621.0, which is now in the default branch of The extra pipe suggested in #231 (comment) is harmless, so you're welcome to keep using that - you don't need to change anything, switching to ( |
Describe the bug
steam-runtime-launcher-service
has a built-in mechanism to wait for it to be ready before proceeding, but Protontricks doesn't use it.To Reproduce
n/a, from source code inspection
Expected behavior
If you run
steam-runtime-launcher-service
(or equivalentlypressure-vessel-wrap --launcher
orSteamLinuxRuntime_soldier/run --launcher
) with the--info-fd
option, then read from that file descriptor until EOF, that's enough to guarantee that the launcher service has either started up or failed to start. This would remove the need to rundbus-send
in a loop.The easiest way to achieve this would be:
bwrap_launcher.sh
, add--info-fd=1
to the parameters passed after--
(1 means standard output);stdout=subprocess.PIPE
;Popen
object'sstdout
:_start_process(...).stdout.read()
If you don't need any of the output, you can just discard it.
--info-fd=1
is in fact the default if you don't ask the launcher to wrap another command (so you're probably already getting this information and just sending it to /dev/null), but explicit is better than implicit.There is man-page-style documentation in https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/bin/launcher-service.md and https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/bin/launch-client.md.
System (please complete the following information):
n/a, from source code inspection
The text was updated successfully, but these errors were encountered: