Hanging on infinite loop

[joelchrist]

Issue description

Codi hangs when writing the following piece of code in JavaScript:

while (true) {
    console.log();
}

Environment

• Mac OSX El Capitan

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 19 2016 20:38:47)
MacOS X (unix) version
Included patches: 1-5
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_old_static
+arabic          +find_in_path    -mouse_sysmouse  -tag_any_white
+autocmd         +float           +mouse_urxvt     -tcl
-balloon_eval    +folding         +mouse_xterm     +termguicolors
-browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     -gettext         -mzscheme        +textobjects
+channel         -hangul_input    +netbeans_intg   +timers
+cindent         +iconv           +num64           +title
-clientserver    +insert_expand   +packages        -toolbar
+clipboard       +job             +path_extra      +user_commands
+cmdline_compl   +jumplist        +perl            +vertsplit
+cmdline_hist    +keymap          +persistent_undo +virtualedit
+cmdline_info    +lambda          +postscript      +visual
+comments        +langmap         +printer         +visualextra
+conceal         +libcall         +profile         +viminfo
+cryptv          +linebreak       +python          +vreplace
+cscope          +lispindent      -python3         +wildignore
+cursorbind      +listcmds        +quickfix        +wildmenu
+cursorshape     +localmap        +reltime         +windows
+dialog_con      -lua             +rightleft       +writebackup
+diff            +menu            +ruby            -X11
+digraphs        +mksession       +scrollbind      -xfontset
-dnd             +modify_fname    +signs           -xim
-ebcdic          +mouse           +smartindent     -xpm
+emacs_tags      -mouseshape      +startuptime     -xsmp
+eval            +mouse_dec       +statusline      -xterm_clipboard
+ex_extra        -mouse_gpm       -sun_workshop    -xterm_save
+extra_search    -mouse_jsbterm   +syntax
+farsi           +mouse_netterm   +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -fstack-protector -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib  -L/usr/local/lib -o vim        -lncurses -liconv -framework Cocoa   -mmacosx-version-min=10.11 -fstack-protector-strong -L/usr/local/lib  -L/usr/local/Cellar/perl/5.24.0_1/lib/perl5/5.24.0/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc -F/usr/local/Cellar/python/2.7.12/Frameworks -framework Python   -lruby.2.3.0 -lobjc -L/usr/local/Cellar/ruby/2.3.1/lib

[fwip]

See: https://github.com/metakirby5/codi.vim/blob/master/doc/codi.txt#L79

I wonder if it would be possible to set a user-configurable time-out value that would stop/kill the interpreter after N seconds? I don't really know how vim async support works.

[metakirby5]

@joelchrist Can you define "hangs?" With +job and +channel, input should still be responsive, but the Codi pane should not update in the case of an infinite loop. Codi only updates the buffer after execution has finished.

@fwip I can see how the timeout would be useful for users that don't have async, but it seems like it's not very helpful for most users, and not helpful in the typical use case in general (where there are no infinite loops, and you always want execution results to be displayed no matter how long they take). Can you elaborate on the idea?

[fwip]

Sorry; I probably shouldn't have mentioned it there, it's not really well-thought out enough for a feature request or anything. I was thinking that a suitably large value (like, say, 10 seconds) would kill jobs that happened to be stuck in an infinite loop, but be long enough to not interfere with any 'normal' usage. If the user set, say, let g:codi_interpreter_timeout = 10 then it would try to clean up after 10 seconds, and if they didn't set a value, it wouldn't kill them at all.

I'm still a very new user of Codi, so take all of my input with a big chunk of salt.

[metakirby5]

@fwip No problem, your input is always welcome :) I think we're all very new users of Codi, since it's only been out for two months. I'm just not sure what benefit a timeout would have for async users (which should be a majority), since on any buffer change, the existing job is killed and a new job is spawned. This should prevent any unresponsiveness in the asynchronous case.

This setting in the synchronous case would be of great value. I'm just not sure how many users would enjoy using Codi at all in the synchronous case anyways, since typing latency makes for a very poor user experience in the first place.

In any case, if this is something you think would be useful, don't be afraid to file an issue!

[fwip]

Oh, I didn't understand that the existing job would be killed as soon as a new one started - that makes a lot of sense!

[systemmonkey42]

After doing exactly this, and hanging codi with the background node task taking 98% cpu, I found that VIM became very slow;

I turned on function profiling and found the following;

FUNCTIONS SORTED ON SELF TIME count total (s) self (s) function 329865 7.637924 3.298504 codi#__vim_callback() 329865 3.204093 <SNR>276_ch_get_id() 329865 1.135327 <SNR>276_codi_handle_data()

I dont know that that all means, but since it appears the while loop is generating an infinite amount of output, vim data handling routines are overwhelmed.

You might consider a maximum number of lines in addition to a timeout, eg, after 1000 lines, consider the repl done and terminate the process.