> Date: Sun, 19 Oct 2014 00:06:50 -0700
> From: Haitao Zhang <zhtprog@gmail.com>
>
> I have reliably experienced UI freezes under the following conditions:
> 1) A large read from a subprocess is in progress (2+MBs, around 2
> seconds on Windows with w32-pipe-read-delay set to 0).
> 2) A mid-sized write is sent to the subprocess, from a not very large source
> code buffer but large enough to block the write. The subprocess will not
> read from its side until it finishes the transfer started in 1.
>
> Killing the subprocess unfreezes Emacs. The error message indicates that
> Emacs blocked on the write, complaing about the process being dead while
> writing. The process buffer, normally mopped up by the process filter,
> is filled with text midway through the transfer, indicating that the process
> filter has stopped getting called. Finally locking out the offending
> blocking write while the read is still in progress has ensured that the
> deadlocks no longer happen. Success of the workaround gives me
> confidence that this is an Emacs bug or feature.

I'm quite sure this is bug #18420, already fixed for the upcoming
Emacs 24.4 release.

> Reading through the Emacs source files, it appears that when user calls
> process-send-* in elisp eventually Emacs calls send_process in
> process.c. If the send blocks it calls wait_reading_process_output,
> which in turn should read pending output. Apparently in my case this is
> not happening and a deadlock occured instead.

It is not happening, because until the above-mentioned fix the code
you described was not executed on Windows, because neither EWOULDBLOCK
nor EAGAIN was ever returned by writes to a pipe.

The fix made the pipes on Windows non-blocking, so now the code you
describe really is used on Windows.

That is why I suggested that you try a later binary.  There are
binaries of the 24.4 pretests floating around, and if you have MinGW
and MSYS/MSYS2 installed, you should be able to build Emacs yourself.