diff options
| author | Léana 江 <leana.jiang+git@icloud.com> | 2026-06-16 15:54:22 +0200 |
|---|---|---|
| committer | Léana 江 <leana.jiang+git@icloud.com> | 2026-06-26 21:59:27 +0200 |
| commit | 5513b9100728c08789fb19d8cfc314a2c8dab876 (patch) | |
| tree | b91429dd95e94057e6cefe6495c362149929ca32 /nix/flake.nix | |
| parent | d36cd2d0369efa6d32948d0713fe79a72ec5fbeb (diff) | |
| download | xmobar-5513b9100728c08789fb19d8cfc314a2c8dab876.tar.gz xmobar-5513b9100728c08789fb19d8cfc314a2c8dab876.tar.bz2 | |
remove " &" and fix zombie processes
" &" was to avoid throwing an exception when the child process has a
non-empty exitcode. However, the error-throwing function is callCommand
and not spawnCommand, so removing " &" shouldn't change the semantic.
https://codeberg.org/xmobar/xmobar/pulls/698#issuecomment-1722323
> callCommand seems to be the closest new function to system, but there
> is a difference: it raises an exception if the child process has a
> non-zero exit code. To preserve the exact behavior would require
> something like spawnCommand (s + "&") >>= waitForProcess.
I was able to reproduce zombie processes with the following steps:
+ running my own xmobar configuration
+ spawning a command that is long running (sleep 10)
+ sending SIGTERM to the xmobar process
After doing so, the sleep command will continue to run.
This PR uses withCreateProcess, which will always wait for the process
to terminate, even when the main thread is asked to exit (SIGTERM).
Note that SIGKILL is not expected to terminate the children.
Diffstat (limited to 'nix/flake.nix')
0 files changed, 0 insertions, 0 deletions
