No lazy

[wincent]

PR Prelude

• I have read and understood YCM's CONTRIBUTING document.
• I have read and understood YCM's CODE_OF_CONDUCT document.
• I have included tests for the changes in my PR. If not, I have included a
  rationale for why I haven't.
• I understand my PR may be closed if it becomes obvious I didn't
  actually perform all of these steps.

Why this change is necessary and useful

See prior version of this PR (#2454) for more discussion.

---

This change is 

[codecov-io]

Current coverage is 84.44% (diff: 100%)

Merging #2473 into master will not change coverage

@@             master      #2473   diff @@
==========================================
  Files            17         17          
  Lines          1903       1903          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits           1607       1607          
  Misses          296        296          
  Partials          0          0          

Powered by Codecov. Last update 48b7cce...7f76b03

[Valloric]

Thanks for the PR!

---

Review status: 0 of 2 files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[vheon]

@homu r=Valloric

---

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[homu]

📌 Commit 7f76b03 has been approved by Valloric

[homu]

⚡ Test exempted - status

[Valloric]

OK, I just reverted this PR because it was causing gvim (but not console vim) to become unresponsive on Linux. Repro steps:

1. Open gvim on linux (with this patch applied).
2. Open third_party/ycmd/ycmd/utils.py (opening other files is likely to exhibit the same problem).
3. Watch gvim get stuck forever and become unresponsive.

@wincent If you could figure out what's going on and how we could have this change without making gvim unhappy, we'd be willing to merge a new version of the change.

@micbou Thanks a bunch for noticing this!

[wincent]

I don't have access to a Linux machine at this time, but if I can obtain access, I'll take a look.

[micbou]

This is caused by a bad interaction between Python's Popen and process forking on UNIX. Consider the following Python program:

import os
import subprocess

proc = subprocess.Popen( [ 'sleep', '1' ] )

pid = os.fork()

is_alive = proc.poll() is None
  
if pid:
    print( 'Parent process: {0}'.format( is_alive ) )
else:
    print( 'Child process: {0}'.format( is_alive ) )

It will output:

Parent process: True
Child process: False

As you can see, the child process incorrectly returns that the Popen process is terminated. The same thing is happening when loading YCM at gvim startup on Linux:

1. YCM is loaded and the ycmd server is started through Popen;
2. gvim forks its process (see :h gui-fork);
3. the IsServerAlive method returns False because of the fork;
4. YCM assumes that the server crashed and read its standard error. This blocks since the process is still running (the error stream is not closed) and thus gvim becomes unresponsive.

However, when loading YCM at VimEnter, gvim already did its fork and the poll() method from Popen works as expected.

In conclusion, I don't think we have much choice here; we can't load YCM at startup.

[vheon]

@micbou as always a great analysis!

In conclusion, I don't think we have much choice here; we can't load YCM at startup.

At least now we know :)

[wincent]

Excellent explanation, @micbou.