> That doesn't look right, because there should not be a complete json message. > If there is, perhaps a call to parse it is missing? > Perhaps a call to channel_parse_json() is needed.
Yes, maybe there is a channel_parse_json() missing somewhere. But as the flow log shows it's also a channel_parse_messages()-call missing. > If the JSON is incomplete we need to receive more text to be able to parse > it. Thus we might as well block on receiving something. Thing is, I think that the JSON is actually complete, but since channel_parse_messages() isn't called it never gets the chance to parse the JSON content. That's how I read the logs at least. > So what is in those 64 bytes? If you look in the channel log it should be > there. You don't quote from a channel log, did you use ch_logfile()? That was just pseudo-logs handwritten :) I ran it again and this time include what is actually read from the channel in channel_read(). Since I do get a few signs placed I can see in the log how it looks like when it works, this is one of the signs that gets placed: RealWaitForChar() is called with 0 delay channel_read() is called from RealWaitForChar(), it reads 63 bytes into the buffer channel_save() is called from channel_read() with the buffer that starts with: [0,[34,"call","sign_place",0,"govim","govimerr",1,{"lnum":6}]] (and 0x0a at the end) RealWaitForChar() is called with 0 delay RealWaitForChar() is called with 0 delay RealWaitForChar() is called with 0 delay channel_parse_messages() is called from parse_queued_messages() channel_peek is called (for part 0) channel_get_json is called channel_parse_json is called channel_peek is called (for part 1) channel_get_json is called channel_peek is called (for part 0) channel_get_json is called channel_parse_json is called channel_peek is called (for part 1) channel_get_json is called channel_get_json is called channel_parse_json is called channel_peek is called (for part 2) channel_get_json is called And when it doesn't work it never gets to the channel_parse_messages() call: RealWaitForChar() is called with 0 delay channel_read() is called from RealWaitForChar(), it reads 64 bytes into the buffer channel_save() is called from channel_read() with the buffer that starts with: [0,[41,"call","sign_place",0,"govim","govimerr",1,{"lnum":12}]] (and 0x0a at the end) RealWaitForChar() is called with 0 delay RealWaitForChar() is called with 0 delay RealWaitForChar() is called with 0 delay channel_peek is called (part 0, I don't know from where) channel_peek is called (part 0, I don't know from where) RealWaitForChar() is called with -1 (as wait_func) Ok, so I see what you referred to with: > In inchar_loop() it should call parse_queued_messages() before blocking, I did run again and logged the inchar_loop() calls, there are only two in the entire run and both with -1 as wtime. So, we end up inside inchar_loop(), before calling wait_func() with a wait_time value set to -1 (that will block). And to ensure that parse_queued_messages() are called before sleeping, either has_pending_job() or channel_any_readahead() must return TRUE, right? That would explain why the patch to channel_any_readahead() works, since it will make it return TRUE? Or should it be another check to ensure that parse_queued_messages() is called before blocking? Best regards, Pontus -- -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/39af4c19-2eaf-4cdd-baef-52ed1094f390%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.