If it takes a while to compile the user's C++ file, the YCM client/server may
run out of threads. Vim gets laggy then.
This is a stopgap measure until I think of something better.
When I initially released this project, I released it under my own copyright. I
have since then worked on it in my 20% time at Google (and want to continue
doing this) and my life becomes much simpler if the copyright is Google's.
From the perspective of how this project is run and managed, **NOTHING**
changes. YCM is not a Google product, merely a project run by someone who just
happens to work for Google.
Please note that the license of the project is **NOT** changing.
People sending in future pull requests will have to sign the Google
[CLA](https://developers.google.com/open-source/cla/individual) (you can sign
online at the bottom of that page) before those pull requests could be merged
in. People who sent in pull requests that were merged in the past will get an
email from me asking them to sign the CLA as well.
Previously, we'd implicitly turn off future notices about unknown extra conf
files if we already raised one exception about it. This breaks when the user
ends up not receiving the "unknown extra conf, load?" message.
Now we only turn off the notice as a result of the user saying "don't load this"
so that if the first request fails to reach them, they'll get a second (and
third etc) request about it.
Fixes#615
This option existed so that the user can tweak it if they found the default idle
timeout too short, for instance if they leave their machine on over the weekend.
This use case is now covered by the new YcmdKeepalive system that pings ycmd
every 10 minutes as long as Vim is running. This prevents ycmd shutting down if
one leaves their Vim instance alone for a long time.
Thus the old option is useless now; ycmd now shuts down after 3 hours of
inactivity, which should only ever happen when its corresponding Vim instance
has shut down abnormally.
By default, a ThreadPoolExecutor will wait at Python interpreter shutdown for
all the threads to stop by themselves before letting the interpreter shut down.
We don't want that for the network requests thread pool, it causes a shutdown
latency if there are outstanding requests. Killing the threads in our pool is
perfectly safe so we can avoid the latency by introducing an
UnsafeThreadPoolExecutor.
It appears that the issue comes from sending a None timeout to Requests. It
seems it's a bug in Requests/urllib3. So we just pick an arbitrary long timeout
of 30s as the default.
Vim still loves to block the main GUI thread on occasion when asking for
completions... to counteract this stupidity, we enforce a hard budget of 0.5s
for all completion requests. If the server doesn't respond by then (it should,
unless something really bad happened), we give up.
Now, every FileReadyToParse event returns diagnostics, if any. This is instead
of the previous system where the diagnostics were being fetched in a different
request (this caused race conditions).
There appear to be timing issues for the diag requests. Somehow, we're sending
out-of-date diagnostics and then not updating the UI when things change.
That needs to be fixed.
The problem was that when you start vim like "vim foo.cc", the FileReadyToParse
event is sent to the server before it's actually started up. Basically, a race
condition.
We _really_ don't want to miss that event. For C++ files, it tells the server to
start compiling the file.
So now PostDataToHandlerAsync in BaseRequest will retry the request 3 times
(with exponential backoff) before failing, thus giving the server time to boot.
These happen rarely and are not a big deal when they do. We still log them to
the Vim message area, but we don't annoy the user with the default, in-your-face
Python traceback.
