Yasuhiro Matsumoto wrote:
> On Monday, September 5, 2016 at 11:30:42 AM UTC+9, mattn wrote:
> > > Isn't the best solution then to have channel_wait() not return an error?
> > > Or is there some way to detect the situation, perhaps by using
> > > LastError(). At least it should only affect Windows, since on Unix we
> > > don't want to make this exception.
> >
> > I say again, This is posssible to be reproduced on Linux.
>
> While the process alive, stdout is not filled in the buffer. But when
> the process exited, buffer should be flushed. So if we change this
> like below to debug output,
>
> -----------------------------------
> diff --git a/src/channel.c b/src/channel.c
> index 10ed42e..15a3f72 100644
> --- a/src/channel.c
> +++ b/src/channel.c
> @@ -59,6 +59,12 @@ static void channel_read(channel_T *channel, int part,
> char *func);
> /* Whether a redraw is needed for appending a line to a buffer. */
> static int channel_need_redraw = FALSE;
>
> +static void debuglog(char* buf) {
> + FILE *fp = fopen("debug.log", "a");
> + fprintf(fp, "%s\n", buf);
> + fclose(fp);
> +}
> +
> /* Whether we are inside channel_parse_messages() or another situation where
> it
> * is safe to invoke callbacks. */
> static int safe_to_invoke_callback = 0;
> @@ -2894,11 +2900,14 @@ channel_wait(channel_T *channel, sock_T fd, int
> timeout)
> while (TRUE)
> {
> int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, &nread, NULL);
> + char buff[256];
> + sprintf(buff, "polling %ld, %d, %ld", nread, r, GetLastError());
> + debuglog(buff);
>
> - if (r && nread > 0)
> - return CW_READY;
> if (r == 0)
> return CW_ERROR;
> + if (nread > 0)
> + return CW_READY;
>
> /* perhaps write some buffer lines */
> channel_write_any_lines();
> @@ -3003,6 +3012,7 @@ channel_close_on_error(channel_T *channel, char *func)
> * died. Don't close the channel right away, it may be the wrong moment
> * to invoke callbacks. */
> channel->ch_to_be_closed = TRUE;
> + debuglog("close");
>
> #ifdef FEAT_GUI
> /* Stop listening to GUI events right away. */
> @@ -3033,9 +3043,6 @@ channel_read(channel_T *channel, int part, char *func)
> sock_T fd;
> int use_socket = FALSE;
>
> - /* If we detected a read error don't try reading again. */
> - if (channel->ch_to_be_closed)
> - return;
>
> fd = channel->ch_part[part].ch_fd;
> if (fd == INVALID_FD)
> @@ -3045,6 +3052,14 @@ channel_read(channel_T *channel, int part, char *func)
> }
> use_socket = fd == channel->CH_SOCK_FD;
>
> + {
> + DWORD nread;
> + int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, &nread, NULL);
> + char buff[256];
> + sprintf(buff, "let's read %ld, %d", nread, r);
> + debuglog(buff);
> + }
> +
> /* Allocate a buffer to read into. */
> if (buf == NULL)
> {
> -----------------------------------
>
> The output become:
>
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 0, 109
> close
> polling 18, 1, 0
> let's read 18, 1
> polling 18, 1, 0
>
> Then, I check GetLastError() to ignore ERROR_BROKEN_BUFFER that occur
> when process exited.
Surprising to see that first it returns an error and then later shows
bytes are available to readl. So ignoring code 109 (I believe that's
ERROR_BROKEN_PIPE) seems appropriate.
--
hundred-and-one symptoms of being an internet addict:
170. You introduce your wife as "[email protected]" and refer to your
children as "forked processes."
/// 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.
