fix: Worker no longer leaves defunct pid on macOS

[scottrbaxter]

I noticed a process on macOS that initially consumes 1400% CPU for a brief moment then becomes a <defunct> (zombie) pid. I was able to trace it back through the CPU Load segment in my p10k config. (screenshots from btop)

Running any command or even simply hitting return (newline) in iTerm spawns a new 1400% CPU pid that almost immediately goes defunct as the new prompt is rewritten. I confirmed this by quickly opening several new tabs in iTerm, each causing an individual (albeit brief) CPU spike before going defunct.

Initial troubleshooting, I determined that disabling the load segment in my prompt make this issue stop, completely.

Further testing, I was able to track this back to _p9k_worker_async _p9k_prompt_load_async _p9k_prompt_load_sync in the _p9k_prompt_load_compute function.

This calls _p9k_worker_async, where eval $async appears to be the culprit, here:

sysopen -r -o cloexec -u fd <(() { eval $async; } && print -n '\x1e') || return

I believe the reason is due to how macOS handles process substitution and signals, combined with the eval call and the potential for the subshell to get stuck. I've provided this solution, which avoids eval and provides an explicit wait call in the parent function after spawning the subshell. This forces the parent to wait for the child to terminate, preventing it from becoming defunct.

There may be a cleaner solution, and if so I'm more than happy to update with suggestions.

This change has been tested and confirmed compatible with these systems:
macOS Sequoia: affected
macOS Sonoma: affected
Debian Bookworm: not-affected

Side note, thanks for making such an amazing zsh theme!

[ryder-gillen-ltk]

when you wait outside of cloexec you have turned the asynchronous worker into an synchronous one.

[romkatv]

Indeed. The fix is wrong but the issue is legit--or at least I don't see why it wouldn't be just from the description. Do you also experience it?