Data racing in keybinding execution

[amerlyq]

Issue description

Several months ago I had simple keybinding for volume up/down:

• EzKey("M-<Page_Up>", lazy.spawn("amixer -q -- sset Master playback 1%+"))

But after upgrade to 0.24.0 my audio channels started to disbalance (having different volume) when using this binding repeatedly e.g. pressing and holding to increase volume.

After investigation it seems amixer is suspectible to data racing conditions (at least with pipewire backend), you can check it like this:

amixer -- sset Master playback 20% && for i in {1..10}; do amixer -q -- sset Master playback 1%+ & done && sleep 1 && amixer -- sget Master
# left=23% vs right=21%

Somehow, earlier qtile wasn't suspectible to this issue, probably qtile had changed sequential execution of keybinding to parallel at some point. Or refactored codebase, so timings between keybindings execution had decreased and now amixer become affected.

---

What I propose:

• Share the flock trick in the docs as the recommended way to bind rapidly spawning keybindings
  lazy.spawn("flock -xFw1 /usr/bin/amixer amixer -q -- sset Master playback 1%+")
• Add option to Key(...) interface to suppress parallel execution for some/all commands, e.g. allowed_in_parallel=False -- for more descriptable way to serialize execution than using flock trick

Version

0.24.0

Backend

X11 (default)

Config

EzKey(
        "M-<Page_Up>",
        # FIXED:(flock): avoid data racing, which disbalances audio channels
        lazy.spawn("flock -xFw1 /usr/bin/amixer amixer -q -- sset Master playback 1%+"),
        desc="Volume up",
    ),
    EzKey(
        "M-<Page_Down>",
        lazy.spawn("flock -xFw1 /usr/bin/amixer amixer -q -- sset Master playback 1%-"),
        desc="Volume down",
    ),

Logs

No response

Required

• I have searched past issues to see if this bug has already been reported, and it hasn't been.
• I understand that people give their precious time for free, and thus I've done my very best to make this problem as easy as possible to investigate.

[tych0]

Somehow, earlier qtile wasn't suspectible to this issue, probably qtile had changed sequential execution of keybinding to parallel at some point.

It has always been parallel in the sense that we fork the command but don't wait for it to exit before returning control to the event loop (e.g. if you spawn firefox instead of amixer, we don't want to wait for firefox to exit). I think it's possible that some of the python core work to speed things up is causing this problem, though.

The simplest solution here IMO would be to add an argument to spawn() that waitpid()s for the spawned task to exit. That way all events and commands they're bound to would be processed serially.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove the status: stale label or comment, or this will be closed in 30 days.