[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs communication with subprocess is slow
From: |
Eli Zaretskii |
Subject: |
Re: emacs communication with subprocess is slow |
Date: |
Fri, 03 Oct 2014 21:32:31 +0300 |
> From: Stephen Leake <address@hidden>
> Date: Fri, 03 Oct 2014 12:51:18 -0500
>
> This may be related to http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18420
>
> I'm using Emacs pretest 24.3.93, with the patch from 18240, on Windows 7.
>
> I've run into another problem with Emacs communication with external
> processes; there seems to be a delay on every task switch. This shows up
> both when sending data to the subprocess, and when reading from it.
>
> I haven't tested this on Debian yet.
>
> The delay is not present in Emacs 24.3 on Windows 7.
>
> When sending the contents of an Emacs buffer (source code to be parsed)
> to the subprocess, if the read buffer in the subprocess is
> large enough to hold the entire contents, no delay is apparent. However,
> if the buffer is smaller, so that several reads are needed, then a delay
> appears.
Sorry, I don't understand: Emacs 24.3 would simply deaqdlock in this
situation, as we have established in bug #18420. But you say that not
only does it not hang, it is even faster. What am I missing?
And what exactly does "large enough" mean here? What sizes are we
talking about?
Also, can you quantify the delays?
> I can use a large buffer in my subprocess for read as a workaround, but
> I have no control over the read buffer in Emacs (perhaps that could be
> added?).
You could try playing with 2 parameters that currently are fixed: the
size of the pipe buffer (set by pipe2 in w32.c, where we use 0 which
AFAIK defaults to 4KB); and the delay used by send_process in
process.c when it gets EAGAIN/EWOULDBLOCK from the 'write' call
(currently 20 milliseconds).
> Should I reopen 18240, or start a new bug?
A new one, of course. This is an entirely different issue.