Danek Duvall wrote: > On Fri, Feb 19, 2016 at 02:56:35PM -0800, Danek Duvall wrote: > > > On Fri, Feb 19, 2016 at 11:21:46PM +0100, Bram Moolenaar wrote: > > > > > > > > Danek Duvall wrote: > > > > > > > The channel tests, when run on a couple of the Solaris boxes I'm on, > > > > fail > > > > fairly consistently on anywhere from two to six tests, each with timeout > > > > errors. If I make the same concession that we do for MacOS, then they > > > > work > > > > consistently. > > > > > > > > I don't like this much, since I feel like there's a race condition > > > > lurking > > > > in here somewhere, but I'm really not sure what it is -- whether it's > > > > simply a race between vim's connect() and python's listen() (though an > > > > explicit sleep in the server code immediately after > > > > server_thread.start() > > > > doesn't help much), or if there's something internal. > > > > > > > > At any rate, the following patch works for now. > > > > > > Thanks. I suspect it has something to do with making the socket > > > non-blocking. Perhaps it helps to set it back to blocking before > > > calling select()? > > > > It doesn't. I'll ask some of our networking gurus at work, see if anyone > > has the time to identify the issue. > > The response I got was that it's working precisely as requested. There's > no guarantee that by the time the user code gets to the select() that the > connect() will have completed in the kernel, so the fact that a zero > timeout ever works is pretty much dumb luck. > > I would suggest that a zero timeout should mean a zero timeout on all > platforms, instead of being silently changed to 1ms -- even if it's not > especially useful on many or most systems -- and that the default timeout > for ch_open() should be 10ms -- long enough for any modern machine to > complete a local connection, and short enough to be invisible to a human > user. The author of the vimscript using this can always override this to 0 > if they know better, but for general cross-platform safety, it probably > should stay at the default for the local case, and probably upped for > remotes.
Thanks for looking into this. I would say that a zero timeout is never useful, since it will always have a good chance of failing. A zero timeout would mean "give it a try and I don't know what it means when it fails. I'll add a remark about using a longer timeout for a remote server. On a local network 10 msec makes sense. A longer timeout would be needed for a remote server. That would make Vim startup slow. Would be nice if this can happen in the background. But that's complicated, lets leave it for later. -- Proofread carefully to see if you any words out. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
