Kill the warmupthread on quit.

[xavierd]

This is fully based on the code of http://stackoverflow.com/questions/323972/is-there-any-way-to-kill-a-thread-in-python.

It works for me, going from a 5s shutdown to an instant one for example/boost.cpp.

It should fix #216.

[tobiasgrosser]

On stackoverflow they state "As noted in the documentation, this is not
a magic bullet because if the thread is busy outside the python
interpreter, it will not catch the interruption."

I see the same behaviour. If I slow down my cpu with CPU freq to model a
slow background parsing, vim (even with this patch) is still hanging on
shutdown until the libclang call returns. However, your patch
significantly shortens the time vim hangs.

I believe what happens is that we interrupt between the call to
index.parse and tu.reparse. And this is actually something that we can
do anyway without the fancy interrupt code, but just the classical way
of checking a variable (isInterrupted) at that point. In
case we want to shut down, the variable is set and the thread will abort
instead of calling ru.reparse().

Cheers,
Tobi

[xaizek]

This fix makes Vim close faster, but it doesn't fix the issue completely. I'm agree with Tobias, that it can't be fixed this way. To really fix the issue an asynchronous call like TranslationUnit_CancelCompletion should be added to libclang.

Another option is to write a library which will run unit parsing in a separate threads using pthread and call pthread_cancel(...) when we need. But it's probably too complex solution.

[oblitum]

Other one is to put the hairy libclang in its place: another process, instead of redesigning it. This is a project I'm working on, using shared memory (initially, maybe permanently) and raw libclang api out of process (with some influence from ClangService). The process can just be killed (in truth I'm not taking this approach since I want persistency, VIM closes freely, the libclang process lives on). Also, as YouCompleteMe is another parallel project, not sure what they have done about this, I've not checked.

[xavierd]

@TobiG: I'll try to see if the exception is effectively being triggered between parse and reparse, but I doubt it. I wrote this code on a slow computer (parse takes 5s), so if what you say is true, I would have to wait a minimum of 5s before vim close, which is not what I observed. But I'll try to confirm that.

@xaizek: As I understand, libclang is not thread safe, and adding a CancelCompletion would require libclang to become thread safe, so I don't think that will happen in the near future.

@oblitum: Yes using multiprocess vim module may be the real answer. However, as process are much heavier than threads, I believe #258 should be fixed before (as I understand the API between thread and multiprocess is very similar, so it shouldn't be too hard to switch to multiprocess). I believe YouCompleteMe is using pthreads.

[tobiasgrosser]

This was superseeded by #392