Document blocking behavior of open::that()

[Seeker14491]

The docs for open::that() don't mention whether the function can block. However, the docs for the deprecated open::that_in_background() say that open::that() is always non-blocking. This information should be in the docs for open::that().

[Byron]

Thanks for the hint!

This is fixed in v3.0.2.

[benjajaja]

open::that() seems to block until the program that opened the argument is closed (on linux).

[Byron]

Can you debug this? Sometimes I have a feeling it also depends on which launcher it actually picks to launch the program, and if the launcher doesn't spawn, open::that() will also hang. Maybe some launchers need an additional flag to make it non-blocking?

[benjajaja]

@Byron it uses xdg-open (xdg-open 1.1.3+) and hangs until the program is closed. When I run xdg-open <path> from CLI it also does not return until the program closes.

[Seeker14491]

I ran into this same issue in my similar opener crate, which also uses xdg-open. To fix it I no longer wait to read the exit code from xdg-open, though unfortunately it means I'm not able to indicate failure in this case.

[Byron]

Thanks for sharing! I think I vaguely remember to have checked for flags, but xdg-open doesn't allow to change that behaviour.

If open should adopt the 'no-wait, no-err-assume-success' strategy then I'd think it would best be moved to the last spot to try all other launchers first, all under the assumption that these will spawn and detach the spawned program.

[benjajaja]

I would just change the docs/description, noting that some launchers might not return immediately.
I guess that open_in_background is deprecated because open is thought to return almost immediately. But perhaps spawning a thread/tokio thread/whatever should be left to the user anyway.

[Byron]

Thanks for sharing!

It's a bit sad that getting this to work for cross-platform applications isn't straightforward. open_in_background() is deprecated because ideally, the application can rely on non-blocking behaviour no matter where it runs just using open().

The best I can imagine is to find a way to check for a status code with timeout for launchers which are known to block. That way one can determine that it is launching the program and thus blocking while releasing the calling thread without blocking too long in the worst case. That way it might work in a correct fashion more often, and by default, even though I don't know if it's good enough to have somewhat racy behaviour builtin to the library. Maybe just assuming success the best choice all things considered.