Hung Podman process makes Aerospace not responsive

[alper]

Not sure what was happening here but it seems that Podman hung and that caused the menu bar icon of Aerospace to not do anything anymore and the entire thing to become quite unresponsive.

Force Quitting Podman fixed the issue.

Maybe something can be fixed here but also leaving this here as a reference for others.

---

Note by @nikitabobko

Related: #131

[SirSimon04]

I can report the same issue. Aerospace was lagging really hard, like up to 10-15 seconds to change the space. Force quitting podman made it perform the change instantly.

[pshomov]

Using AeroSpace v0.14.2-Beta 0cb8dbd I get the same problem but with WebStorm.
AeroSpace remained unresponsive until I restarted WebStorm. I suspect an easy way to reproduce this issue would be to have a fake macOS hung process.

[3541]

Yep, this seems to happen when any macOS application hangs. I have seen it with JetBrains IDEs and VS Code.

[3541]

Here is a simple example program which reproduces the issue when the "lock" button is clicked

#import <atomic>
#import <chrono>
#import <csignal>
#import <thread>

#import <Cocoa/Cocoa.h>

namespace {

std::atomic_bool LOOP { false };

void handle(int) { LOOP.store(false, std::memory_order::relaxed); }

} // namespace

@interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate>
@end

@implementation AppDelegate

- (void)foo {
    using namespace std::chrono_literals;

    LOOP.store(true, std::memory_order::relaxed);
    while (LOOP.load(std::memory_order::relaxed)) {
        std::this_thread::sleep_for(2s);
    }
}

- (void)applicationDidFinishLaunching:(NSNotification*)aNotification {
    NSWindow* window = [[NSWindow alloc]
        initWithContentRect:NSMakeRect(100, 100, 400, 300)
                  styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable |
                            NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable
                    backing:NSBackingStoreBuffered
                      defer:NO];
    [window setDelegate:self];
    [window makeKeyAndOrderFront:nil];

    NSButton* button = [[NSButton alloc] initWithFrame:NSMakeRect(150, 135, 100, 30)];
    [button setTitle:@"Lock"];
    [button setTarget:self];
    [button setAction:@selector(foo)];
    [button setBezelStyle:NSBezelStyleRounded];
    [[window contentView] addSubview:button];

    [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
}

- (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication*)sender {
    return YES;
}

@end

int main(int argc, char const* argv[]) {
    std::signal(SIGUSR1, handle);

    @autoreleasepool {
        NSApplication* application = [NSApplication sharedApplication];
        AppDelegate*   delegate    = [[AppDelegate alloc] init];
        [application setDelegate:delegate];
        [application run];
    }

    return 0;
}

And here is a flamegraph of the hang:

Not sure I entirely understand what is going on here, in particular why it appears to be stuck in cleanup/window disposal code—there should not be any windows getting closed to clean up at the time.

[3541]

I wonder whether the global accessibility API timeout of 1 second is a bit too high, given that:

• It appears hung applications will always consume the full timeout.
• We touch every application and window on every input in detectNewWindowsAndAttachThemToWorkspaces().

[theherk]

I created and have been using NeovideProject. The way it works leaves the shell wrapper alive in the background until the managed instance is closed. This is intended, but it making Aerospace unusable. If anybody is so inclined, maybe you can recommend a way I can accomplish the same thing without holding this process. But when I close these instances, Aerospace works like a champ again. Bummer, because this workflow is excellent.

I take all that back. After fixing the issue where the wrapper was hung, the issue persisted. So I checked without this application; just running Neovide directly. Turns out the issue is with Neovide for some reason.