macOS: Repeated main-thread hang in CAMetalLayer::nextDrawable due to setAllowsNextDrawableTimeout: NO #53390

Reproduction steps

1. Use Zed Preview (0.231.1) on macOS with an external monitor.
2. Leave Zed running for extended periods (hours), optionally with agent/ACP sessions active.
3. The Zed UI becomes completely frozen — the entire process is kernel-suspended.
4. Force quit is required to recover.

The hang reproduces reliably after idle periods, after sleep/wake cycles, or when other processes create IOKit contention (Chrome GPU activity, etc.). I have captured 7 independent hang reports over 5 days, all showing the same root cause.

Observed behavior

The main thread blocks indefinitely in CAMetalLayer::nextDrawable because setAllowsNextDrawableTimeout: NO is set in metal_renderer.rs:162. When any external factor delays IOKit (another process holding a kernel rwlock, GPU pressure, sleep/wake), nextDrawable blocks forever, macOS detects the hung main thread and kernel-suspends the entire process, which prevents GPU work from completing — creating a deadlock.

Hang Report Analysis (7 incidents)

Key observations:

• Every thread in the Zed process shows (suspended) — this is a process-wide kernel suspension, not a userspace deadlock.
• The main thread always ends in _sigtramp → kernel suspended at kernel.release.t8122 + 753348.
• Hang Collaborative code editor for internal use #6 captures the full stack showing the exact blocking path (see below).
• The hang occurs with different external triggers (MxNotify deadlock, Chrome IO, etc.), confirming it is not caused by any specific external process but by Zed's vulnerability to any IOKit contention.
• Hang Add a README with a high-level roadmap #7 occurred after removing MxNotify entirely, proving the bug is in Zed.

Full stack trace from Hang #6 (22.31s, most detailed)

Thread 0x1d1e846  DispatchQueue "com.apple.main-thread"(1)  Thread name "main"
  14  start + 7184 (dyld)
    14  main + 52 (zed)
      14  std::rt::lang_start_internal
        14  zed::main
          14  Application::run
            14  MacPlatform::Platform::run
              14  -[NSApplication run]
                14  _DPSNextEvent → _DPSBlockUntilNextEventMatchingListInMode
                  14  _CFRunLoopRunSpecificWithOptions
                    14  __CFRunLoopRun
                      14  __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
                        14  _dispatch_main_queue_drain
                          14  _dispatch_source_invoke
                            14  gpui_macos::window::step
                              14  Window::new (step closure)
                                14  Window::draw → MacWindow::PlatformWindow::draw
                                  14  -[CAMetalLayer nextDrawable]        ← BLOCKS HERE
                                    14  CAMetalLayerPrivateNextDrawableLocked
                                      14  -[CAMetalDrawable initWithDrawablePrivate:layer:waitStart:]
                                        14  -[IOSurfaceSharedEvent initWithOptions:]
                                          14  IOConnectCallMethod → io_connect_method
                                            14  _sigtramp + 0
                                             *14  kernel (suspended)

Full stack trace from Hang #4 (layout path)

Thread main:
  14  gpui_macos::window::step
    14  Window::new (step closure)
      14  Window::draw
        14  gpui::elements::list::StateInner::layout_items
          14  Div::request_layout (agent_ui)
            14  MarkdownElement::request_layout
              14  MarkdownElementBuilder::pop_div
                14  _sigtramp → kernel suspended

Root cause

In crates/gpui_macos/src/metal_renderer.rs:162:

let _: () = msg_send![&*layer, setAllowsNextDrawableTimeout: NO];

This disables the drawable timeout on CAMetalLayer. Per Apple documentation, when this is NO, nextDrawable() blocks indefinitely if no drawable buffer is available. Combined with:

1. set_maximum_drawable_count(3) — only 3 drawables in the pool
2. Synchronous presents_with_transaction paths in display_layer and windowDidBecomeKey that call wait_until_scheduled() on the main thread
3. VRR/InputRateTracker sustaining continuous presentation during active input

If the GPU pipeline stalls for any reason (IOKit contention from another process, sleep/wake, memory pressure), all 3 drawables remain in-flight, and the next nextDrawable() call blocks the main thread forever. macOS then kernel-suspends the entire process, which prevents GPU command buffers from completing — a circular deadlock.

Suggested fix

Change setAllowsNextDrawableTimeout to YES (the default), or handle the nil return from nextDrawable() when it times out:

// Option A: re-enable timeout (simplest)
let _: () = msg_send![&*layer, setAllowsNextDrawableTimeout: YES];

// Option B: handle nil drawable gracefully
let drawable: *mut Object = msg_send![&*layer, nextDrawable];
if drawable.is_null() {
    // Skip this frame, try again next vsync
    return;
}

Related issues

• Zed UI hangs after long idle in Codex/ACP agent chat; agent continues in background while ACP hits reconnect errors #51058 — Same nextDrawable hang pattern after long idle with ACP/Codex (closed, couldn't repro)
• Zed is sometimes unresponsive when the OS awakes from sleep #7940 — Unresponsive after OS sleep/wake (open since Feb 2024, P1, 44 comments)
• Zed editor freezes and is not clickable #50269 — Editor freezes after wgpu update (open, P1, Linux but same class of bug)

Zed version and system specs

Zed Preview: v0.231.1 (20260402.194205)
OS: macOS 26.3.1 (Build 25D771280a)
Memory: 24 GB
Architecture: aarch64 (Apple M3)
Display: DELL U4025QW 5120x2160 (external) + built-in 4608x2880
Hardware: Mac15,12 (MacBook Air M3)