nvim freezes on deoplete-go init
svanharmelen opened this issue · 17 comments
If I remove lines 103 until 111 from this commit everything works as expected again.
To be more precise, things hang on this command until I kill gocode:
self.get_complete_result(self.buffer, context, kill=True)
Ping @zchee
@svanharmelen Please upload minimal init.vim and the sample code.
I will check it.
@svanharmelen Oh, really? I haven't that problem. Hmm...
Anyway, I want to minimal init.vim too.
@Shougo Thanks ping.
@Shougo @zchee it's very hard to describe how this fails so I'm debugging it myself... I found that if I reopen a saved session with 3 windows, it sometimes creates a process for each window?
I tried this by closing on window and reopen the session again and this time it only had 2 of the same processes. So somehow it spins the same process multiple times which causes the hang/lockup it seems.
Any pointers on how to move forward?
@svanharmelen Ah, maybe understands that's situation. If on_init more than once call, gocode might be a freeze.
I think the solve way is calling on_init only once with fix deoplete-go or any use deoplete core feature, or checks gocode unix socket for whether the already launched gocode daemon. (and remove kill=True if launched)
Or, gocode is very fast even if without AST cache, so remove on_init from deoplete-go.
@zchee I updated the comment a little as it seems that the on_init is triggered multiple times, only when I start switching windows as soon as the session has loaded.
But that does not seem the be the issue as in that case the processes would have different autocomplete filenames and offsets (all windows display different files).
So when I do not switch windows after opening the session I see the on_init is only called once, but still I see multiple of the same process being started with the same autocomplete filename and offset (as shown in the previous screenshot).
Personally I do not think the caching calls make things noticeable faster, so I would delete all the dummy calls that are only added for the initial caching (in both the on_init and on_event functions).
@svanharmelen Thanks for a very detailed comment :) I'll check it out later.
But yeah, gocode is very faster than other languages parser. I will debug it, but maybe better to delete dummy caching.(also json cache - it's buggy :P)
Thanks. And indeed I don't use any of the caching stuff... Things are fast enough without it IMHO 😉
@svanharmelen yeah, basically json cache for no imported package completion. but gocode has been implemented this feature. but return mix-in method if duplicate stdlib package name.
I want to fix it on gocode core code. after that, will json cache also remove.
@zchee any progress on this? Thx!
@svanharmelen Ah, just forgot. very sorry...😱
I'll fix it. (means, remove on_init only)
That would be great, thanks!
@svanharmelen Just a question and just in case,
Do you think good as to remove both the on_init and on_event functions?
Yeah, I would remove both the dummy calls. Tested this locally and do see any downsides (also not any noticeable drawback in speed)...
@svanharmelen OK, got it. I'll remove it now :)
@svanharmelen Done :)
Cool, thx @zchee!