Re: process_send_string blocks?

[Eli Zaretskii]

> From: Stephen Leake <address@hidden>
> Date: Sat, 06 Sep 2014 03:09:22 -0500
> 
> I'm trying to use a background process to parse buffer text, and send
> results back to Emacs.
> 
> For large buffers, Emacs hangs; only killing the background process
> externally recovers. This does not happen for small buffers (< 5k bytes?).
> 
> It appears that process-send-string is blocked on a full IO send queue,
> while the background process is also blocked on a full IO send queue.

Please tell the details of how did you determine this.

> On reading process.c, I believe this should not happen, if the OS supports
> EWOULDBLOCK. 
> 
> Is that true, even when there is only one call to process-send-string that
> sends the entire buffer?

Not sure what are you asking here, since you say you've read the code
and saw the handling of EWOULDBLOCK.

> I'm running on Windows 7, using the Windows binary
> emacs-23.4-bin-i386.zip from the FSF FTP site.
> 
> Is EWOULDBLOCK supported on this system?

Not on writes to pipes, AFAIK.

> I'll try compiling Emacs from source so I can run the debugger; I've
> never tried that on Windows before.

Please do that with the latest pretest, as 24.3 is by now ancient
history.

Also, I suggest to use the latest version 7.8 of GDB, which you can
find here:

  http://sourceforge.net/projects/ezwinports/files/?source=navbar

(Please be sure to read the instructions on the download page, near
its end, which also appear in README.txt, about setting Guile- and
Python-related environment variables.)

To get you up to speed: each subprocess has a dedicated reader thread;
see w32proc.c:reader_thread.  That thread attempts to read 1 byte from
the pipe, and if succeeded, it uses an event object to communicate to
the main (a.k.a. "Lisp") thread that it has read something; sys_select
should then see that and tell the main thread it can read from the
pipe.  It then waits for acknowledge from the main thread before it
attempts to read more.

Writing to the pipe is implemented in w32.c:sys_write (the calls to
'write' elsewhere in Emacs are redirected there).  This runs in the
context of the main thread.

The buffer size for the pipe is defined in w32.c:pipe2.  We pass zero
to the _pipe function, which means "use the default buffer size".  I
couldn't find any information about that default, but you could try
using some specific sizes there (make them integral multiples of 16K)
and see if that makes any difference in your situation.

The first thing I'd do is attach GDB to the hung Emacs and see where
each one of these 2 threads is parked.  (Note that there are more
threads in a running Emacs than just these 2.)

Finally, it is better to continue all this on the bug tracker, perhaps
as part of bug #18396, or a new bug report, if you don't want to mix
up these 2.