Improve handling of cwd fetching (for network mounts)
Related to #6110, the fix there is only partial.
Detailed steps to reproduce the problem:
- Use a network mount which rarely will take a long time to handle the proc_pidinfo syscall to fetch cwd. While it sucks that this happens, iTerm 2 shouldn't freeze.
What happened: iTerm 2 freezes for a while (spinning wheel).
I have already traced through the full debuglog.txt and found the important lines as well as through the code. There are two major problems:
iTerm 2 uses a single serial queue for all proc_pidinfo syscalls, which will all timeout for as long as it takes the mount to handle the syscall. This is a problem since it repeatedly calls that syscall for every single process on the single queue. Recommended workaround: move the cwd fetching code to a separate queue, use an overcommitting concurrent queue, or use a serial queue pool.
Although iTerm 2 does have some code to fetch the cwd in the background, it also has another codepath that will block the main thread. This code path will trigger a sync read of the cwd. Perhaps that line can be safely removed or swapped over to another async read?
What should have happened: iTerm 2 doesn't freeze.