Dealing with suspended/busy applications
- Dominant language
- C
- Stars
- 29.6k
- Forks
- 750
- PR merge metrics
- No merged PRs in 30d
Description
Sort of related to #599, but this is a more general problem. In short, the issue is that the AX API is blocking. If we try to interact with an application that is currently suspended, we will halt until the AX API times out (currently set to 1 second).
The main issues are:
1. If an application is suspended when yabai is launched, we are unable to observe this application and it will go untracked until the application is *restarted*, or yabai is *restarted* after the application has become responsive. This could potentially also happen if the application becomes unresponsive during or shortly after startup, before yabai is able to subscribe to notifications.
2. If an application becomes unresponsive mid-session, and we try to interact with it in any way (get windows, move a window, etc.), it will block and the request will silently fail.
Issue 1. can more or less be solved by deferring the initialization of unresponsive applications til they report back as being responsive.
Issue 2. is tricky and there are many different ways to approach this, but none are really all that great.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing yabai's AX API interactions during application startup and window operations, focusing on suspended or unresponsive applications. Reproduce both reported cases and document behavior around the one-second timeout; done requires defining and validating a non-blocking handling strategy for initialization and mid-session requests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, macos
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100