Multiple blocking spawn calls to Git are freezing Atom intermittently

[nathansobo]

At least in this session, I'm noticing that every time I save, Atom becomes unresponsive. Turns out we're shelling out to Git a bunch and the calls are blocking for ~60ms each. That seems abnormally high to me. I tried to save a profile but it seems like the ability to save them has regressed, so here's the screenshot. I think we need to get to the bottom of why spawning subprocesses can end up blocking the thread for this long.

After reloading the window, the calls block for less time again.

Versions

Atom Version (atom --version): 1.14.0-dev-3b24a33b1
GitHub Package Version (git --git-dir ~/.atom/packages/github/.git rev-parse head): 54a2f754e0cd41d1455b522f9a3025d4b52d9232

[nathansobo]

Here's another example of Atom getting into a state where the event loop is blocking for around 4 seconds every time I open the fuzzy finder. This time I was running on the Electron 1.4 branch and was able to save the timeline. Pictured below is one of the many stack frames with multiple ~50ms spawn calls.

I honestly don't feel comfortable shipping this package as part of the default distribution until we get to the bottom of these pauses.

/cc @BinaryMuse @iolsen

TimelineRawData-20170304T105102.json.zip

[nathansobo]

I captured a native profile of the misbehaving events and will upload that as well. The archive attached to this comment contents a saved Instruments trace as well as a timeline captured during part of the native tracing.

Looks like we're blocking in a native function called _sigtramp in libsystemplatform.dylib:

blocking spawn timeline and instruments.zip

[nathansobo]

My knowledge of this kinda stuff is still pretty thin... @vmg I'm wondering if you might have some pointers or ideas for how I could further investigate the signal trampoline eating a bunch of time in the above-pictured profile? My thoughts thus far...

• Maybe a signal handler is taking a long time to run and we just don't see it in the profile for some reason, maybe because we jumped to it?
• Maybe the signal handler ran fine and we're blocking on switching back into the non signal handling user code for that thread for some other reason?
• Presumably libuv is sets up signal handers to interact with the child process, in this case git. Is there something git could be doing to make us block in the signal trampoline a long time? Seems like this process would be isolated from it.

[smashwilson]

Just some preliminary research into what could be causing this:

• uv_spawn source. I see a lock on &loop->cloexec_lock and a busywait on a pipe to wait for the child process' execve call to complete. There's also some potentially blocking synchronization code in installing the signal handler. I'd guess we'd see different stacks in your profile if either of those were the culprit.
• The SIGCHLD handler that's installed is here. I'm not sure I follow what's going on with that pending queue... but it does look like the process' exit callback is invoked from the signal handler. Maybe that's hiding the real culprit?

[smashwilson]

One likely approach to mitigating this will need to wait on the availability of WebWorkers in Electron.

/cc @BinaryMuse