Repository navigation
Vim process spawned by MacVim uses TASK_UNSPECIFIED role #1594
Description
Steps to reproduce
- Open a new MacVim window
- Run
sudo taskinfo MacVim; you should seeeff role: TASK_BACKGROUND_APPLICATIONandeff qos ceiling: THREAD_QOS_UNSPECIFIED - Run
sudo taskinfo Vim; you should seeeff role: TASK_UNSPECIFIEDandeff qos ceiling: THREAD_QOS_LEGACY
Expected behaviour
sudo taskinfo Vim should have similar output to sudo taskinfo MacVim. In particular, the Vim process being clamped to THREAD_QOS_LEGACY means it’s heavily deprioritized by the scheduler relative to other user-visible apps. This means that the clamped Vim process can be starved of CPU time by the unclamped MacVim GUI process.
Launching command-line Vim with taskpolicy -a vim rectifies this issue. MacVim can achieve the same effect programmatically by calling task_policy_set with TASK_DEFAULT_APPLICATION after spawning the Vim process.
Version of MacVim
r181
MacVim installation method
Homebrew Cask
Environment
macOS version: 15.6 (24G84)
Logs and stack traces
Vim and MacVim configuration where issue is reproducable
No response
How was MacVim launched?
- by launching MacVim.app in macOS (by using the Dock, Spotlight, or the
opencommand) - by running mvim/gvim in the terminal
Issue has been tested with clean configuration
- by running
mvim --clean(orgvim, supplied by MacVim distribution). You can also use the File → "New Clean Window" menu item within MacVim. - by running
vim --clean(in terminal, supplied by MacVim distribution) - by running
vim --clean(in terminal, other suppliers, e.g. /usr/bin/vim)
Activity
lunacookies commentedon Aug 21, 2025
If you let me know where to start looking I’d be happy to write a PR for this myself! Also, I believe switching from DO to XPC (cc #1157) would get you this behavior for free, since XPC takes care of importance boosting and so forth – maybe that’d be the better approach.
eirnym commentedon Aug 22, 2025
I'm not sure that XPC wouldn't be visible to other applications.
Security risks I see with XPC itself:
Hardening the first point is easy, but I don't like an idea to loose privacy on what am I typing on the second.
eirnym commentedon Aug 22, 2025
@lunacookies
I'd like to understand an impact of the original issue.
What CPU-intensive tasks do you use to make it visible?
lunacookies commentedon Aug 22, 2025
Any time the system is under heavy multithreaded CPU load at Default or especially User Initiated QoS (e.g. source code compilation, Instruments’s “data projection” step, etc) the Vim process gets prioritized away into oblivion. This feels very sluggish and choppy at best, and at worst leads to ~1 second-long hangs while the process is starved of CPU time. FWIW this happens with CLI Vim, too (since everything run from the CLI defaults to being clamped to Default QoS).
eirnym commentedon Aug 23, 2025
I know how it feels. I experience the same with the whole system when I compile something heavy longer than 10 seconds, e.g. update some packages. Then I just pause what I've doing and wait for a little while.
Rust easily consume all available threads and resources and even C++ compilation doesn't consume so much CPU. For example, compilation of
ffmpegvsuv, first one will just take some time and very light CPU consumption anduvcompilation will take all CPU for compilation time.PS: I have MBA M2
eirnym commentedon Aug 23, 2025
Reducing threads cargo uses works well for the whole system
ychin commentedon Aug 26, 2025
Thanks for reporting the issue. This issue feels like a Vim specific issue. As you said, it happens in CLI Vim as well, including both the macOS system Vim and Homebrew Vim (or any Vim that you compile manually). Also happens for Neovim.
When you manually change it using
taskpolicy -a vimdo you actually see a noticeable change and have concrete measurable results? Or just "you think it should make it better"? I'm asking since there isn't a lot of documentation available on what the "legacy" QoS limit means and I'm trying to understand if the name could be misleading. From looking around it seems to suggest the "legacy" is just the default queue. Is there any documentation specifically that you see that would suggest it needs to be tweaked?But this probably should be filed at https://github.com/vim/vim/issues/ instead since it's not a MacVim specific issue.
Let's leave the XPC discussion to the other issue. I don't think it's really related to this. It is possible that the slowdown when a machine is loaded is due to the DO inefficiencies (which you can test by seeing if the terminal Vim becomes sluggish) but if that's the case it would indicate that this task info issue is a red herring.
lunacookies commentedon Aug 26, 2025
Good point! Arguably every TUI app should address this.
Yes. I’m not sure how to measure frame rate here, so a screen recording of CLI Vim in Terminal will have to suffice. The left Terminal window is just
vim, and the right one istaskpolicy -a vim. First I demonstrate responsiveness without any significant system load (the responsiveness is identical), and then I compile and run a little test program which loads all cores with a busy loop at User Initiated QoS and compare once more. Hopefully it comes across how much more responsive the right window is (and how long the left window takes to process all the input events) when the system is under load.Screen.Recording.2025-08-26.at.4.09.17.PM.mp4
In the context of the Darwin kernel, “legacy” means Default QoS. I assume this is because Apple considers use of the Default QoS class legacy behavior, only appropriate as a safe default for non-main-thread work with no specified QoS.
taskinfouses the kernel’s terminology because it’s dumping out data structures defined by the kernel. So,eff qos ceiling: THREAD_QOS_LEGACYmeans the process is clamped to Default QoS.Default QoS is not intended to be used for anything, actually; since Vim renders UI (though text-based that UI may be) its main thread is supposed to run at User Interactive QoS. You can find any number of sources corroborating this; here’s one example. The OS applies User Interactive to the main thread by default for non-daemon processes, it just doesn’t have any visible effect because the whole process is clamped to Default.
lunacookies commentedon Aug 26, 2025
I’ve submitted PRs to Vim and Neovim, so I think this issue can be closed!
ychin commentedon Aug 27, 2025
Please link to them so it's easier to reference?
lunacookies commentedon Aug 27, 2025
vim/vim#18120 and neovim/neovim#35488
SALEH55155 commentedon Oct 29, 2025