Yukihiro Nakadaira wrote: > > > > > test_channel.vim fails with Win32 CUI Vim. > > > > > > > > > > What the following patch fix is > > > > > 1. Vim sleep 5 msec even when timeout=0. > > > > > 2. channel_handle_events() closes channel when there is no input. > > > > > 3. ":sleep" command does not read channel (I am not sure where is the > > > > right > > > > > place to call channel_handle_events()). > > > > > > > > Thanks! > > > > > > > > For Unix checking for events happens in mch_breakcheck(). And any > > other > > > > place where RealWaitForChar() is called. > > > > > > > > I hesitate to add channel_handle_events() in mch_breakcheck, it might > > be > > > > too slow. Perhaps it's better to put it inside > > parse_queued_messages(). > > > > That sort of makes sense. And we can remove the other calls to > > > > channel_handle_events() since parse_queued_messages() is called there > > > > already. They were actually in the wrong order. > > > > > > > > Let me make that change. Please check if it works. > > > > > > It works fine. > > > > > > > > > > Did you look at the problem that ch_read() doesn't timeout for Win32? > > > > It's disabled in the test for now. > > > > > > > > > > To implement timeout, we need to use select() instead of > > WSAAsyncSelect(). > > > Patch is attached. With this patch, Vim checks channel each 100 > > > milliseconds while waiting window message. > > > > Hmm, this completely removes the asynchronous handling of messages. > > That is strange, I thought we needed that. > > > > Can't we have both asynchronous handling as soon as a message arrives, > > and another way to wait for something to arrive in ch_read()? > > I suppose that instead of using select() we would use pPeekMessage() and > > loop with a short sleep in channel_wait(), like we do for pipes. > > > > I tried loop with PeekMessage() but I could not figure out how to > implement it when there is multiple channel. > > I also tried recv() with MSG_PEEK, but it did not work. > > I think my patch is not so different because WM_NETBEANS is handled > only when we call GetMessage(). Maybe we also need to call > channel_handle_events() in gui_mch_update() to make it same with > current behavior. > > Perhaps we can use Overlapped I/O to wait both channel and message without > delay. > > Channel polling in the message loop is also required for pipe. Because > WSAAsyncSelect() can not handle pipe.
Thanks for the explanation. Let me include this patch, at least it makes one more test pass. That 100 msec wait seems a bit long. Perhaps we can make it short the first time and longer when looping? Let's see if there are more improvements we can make. -- There can't be a crisis today, my schedule is already full. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ 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]. For more options, visit https://groups.google.com/d/optout.
