bug#18420: 24.3; interaction with external process hangs emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: 18420@debbugs.gnu.org
> Date: Mon, 08 Sep 2014 23:18:39 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Did you try replacing accept-process-output with sit-for?
> 
> The current code has:
> 
>     (accept-process-output process 0.1)
> 
> This waits up to 0.1 seconds for output from the child process
> ada_mode_wisi_parse (or any other process, but there are none in this
> setup). In practice in this scenario, it returns much sooner than 0.1
> seconds; there is some output very quickly after sending any part of
> the buffer contents.
> 
> Replaced with:
> 
>     (sit-for 0.1)
> 
> This performs redisplay, then waits for SECONDS seconds or until "input"
> is available. The wait is done with 'read-event', which reads from "the
> input stream". So apparently this means user input, not child process
> input.

No, sit-for also reads from subprocesses, because it calls 'pselect',
which listens to subprocesses as well.  What's more important, it
acknowledges the "read ready" signal sent by the reader thread, and
releases it from its wait.

> > How about enlarging the 2nd argument to accept-process-output -- did
> > you try that, and if so, did it have any effect?
> 
> tried:
> 
>     (accept-process-output 1.0)
> 
> This hangs.

It didn't hang for me in the simple program I just posted.  Not sure
why the difference, but it isn't worth our time to figure that out,
since the solution is at hand.

> It doesn't change the child process behavior. I was hoping it would
> change the emacs side, allowing it to at least check for C-g every 0.1
> seconds. Hmm, I'm not clear that accept-process-input checks for input
> events.

What do you need by "input events"?  Whenever 'pselect' is called, on
Windows it monitors the C-g keypresses as well (grep for
"interrupt_handle" in the sources).

> > Can you tell how much did it write to the pipe at that point?
> 
> No, that info is not tracked in the current code. I can add it.
> 
> The parser has read 2935 bytes.

If reading that much could cause it to write more than 4KB of output,
then it will block, and won't read more until Emacs reads its end of
the pipe.

> MinGW: not sure what this means; the runtime is just a bunch of
> packages.

The version is in the header _mingw.h.

> mingw-w64-i686-headers-git 4.0.0.4210.0177153-1

The version of the w32api is in w32api.h.