> Perhaps what happens is that there is readahead, but it's not sufficient > to parse more. Then we busy-loop here. What we could do is get the > length of the typeahed (or better: a hash) and if it's the same as last > time, ignore it.
Yes, that sounds like a plausible explanation and a good idea. My C is unfortunately way too rusty to submit a patch, but I'd be more than happy to try out any patches if you'd like confirmation before pushing a change. > It says waiting for 30 sec, but there appears to be a gap of 115 sec. The job itself is initiated via job_start() with a timeout of 30000, but that timeout never occurs when vim hangs like this. I killed it manually after 115 sec. tisdag 26 april 2022 kl. 11:23:07 UTC+2 skrev Bram Moolenaar: > > > Thanks for the response. I haven't tried via terminal window, that > sounds > > like a good idea to investigate. > > > > The reason I think feedback() is innocent here is that there are other > > tests as well that fails, that aren't using feedkeys() at all. I did > find > > one of them that is fairly small where we basically just open a file, > move > > the cursor and delete two lines: > > vim ex 'e main.go' > > vim ex 'call cursor(9,1)' > > vim ex 'normal 2dd' > > > > The commands are sent via a channel and executed on the vim side inside > a > > callback handler > > ( > https://github.com/govim/govim/blob/3dce913d76ea92ddd2e6a43fad8aebb72284f9c4/plugin/govim.vim#L262-L276 > ). > > > > A interesting thing that I did find while debugging is that simply > adding a > > sleep to channel_read_block_json() (where the new coded was added in > > v8.2.4699) changes the behaviour so that the tests pass: > > @@ -3999,8 +3999,10 @@ channel_read_json_block( > > > > // channel_parse_messages() may fill the queue with new data to > > // process. > > - if (channel_has_readahead(channel, part)) > > + if (channel_has_readahead(channel, part)) { > > + do_sleep(200L, FALSE); > > continue; > > + } > > Perhaps what happens is that there is readahead, but it's not sufficient > to parse more. Then we busy-loop here. What we could do is get the > length of the typeahed (or better: a hash) and if it's the same as last > time, ignore it. > > > Since we do have a bunch different tests that started to fail I would > > really like to understand what is going on, might very well be that > > v8.2.4699 uncovered something we are doing wrong at our side. > > > I also captured two channel logs, one where it fails and the other that > > pass (with > > sleep): > https://gist.github.com/leitzler/c66e9a1b181e15516ff73cfdff530a14. > > The interesting part is at the end of broken.log where I manually kill > the > > test at 115.17, but vim still remains running at 100% CPU afterwards: > > > > 0.944675 RECV on 0(sock): '[0,[85,"ex","normal 2dd"]] > > ' > > 0.944682 : looking for messages on channels > > 0.944694 on 0: Getting JSON message 0 > > 0.944699 on 0: Invoking channel callback <SNR>17_define > > 0.944770 : SafeState: reset: ins_typebuf() > > 0.944858 SEND on 0(sock): '[97,["callback",85,[""]]] > > ' > > 0.944923 SEND on 0(sock): > > > '[98,["function","function:GOVIM_internal_BufChanged",[1,9,11,-2,[{"lnum":9,"col":1,"added":-2,"end":11,"lines":[]}]]]] > > ' > > 0.944936 on 0: Blocking read JSON for id 98 > > 0.944941 : looking for messages on channels > > 0.944945 on 0: Waiting for up to 30000 msec > > 0.945009 RECV on 0(sock): '[96,["",""]] > > ' > > 0.945017 : looking for messages on channels > > 115.174200 : raw terminal output: "^[[24;1H^[[m^[[0m" > > It says waiting for 30 sec, but there appears to be a gap of 115 sec. > > > -- > Over the years, I've developed my sense of deja vu so acutely that now > I can remember things that *have* happened before ... > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e036f94e-4848-4a80-8237-dacc77fffa42n%40googlegroups.com.
