bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18626: 24.3.94; communication with subprocess is slow


From: Eli Zaretskii
Subject: bug#18626: 24.3.94; communication with subprocess is slow
Date: Wed, 08 Oct 2014 16:53:12 +0300

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: 18626@debbugs.gnu.org
> Date: Wed, 08 Oct 2014 08:29:59 -0500
> 
> The cause for this is the Sleep in _sys_read_ahead in w32.c. This is
> called from reader_thread after the wait for a single char read
> succeeds. The default wait is 50 ms, set by the elisp variable
> w32-pipe-read-delay. Setting that to 0 gives:
> 
> (pipe-torture-read "/Projects/emacs/emacs-24.3.94/src/xdisp.c")
> 0.180000, 0.095000
> 
> only a factor of 2 slower than command-line cat.
> 
> w32-pipe-read-delay is a global variable. The comment in _sys_read_ahead
> says there are problems with subprocess interaction when setting this to
> 0 on some systems. If that is still true, we may need to change this to
> a per-subprocess setting.
> 
> In my real application, let-binding w32-pipe-read-delay for a short time
> is possible, and a reasonable workaround.

I think I will set that to -1, on the trunk, except on Windows 9X
systems.  That should cause the reader thread yield its time slice
before returning.  Can you see how this affects your use case?

As for the effect of this on non-Windows 9X systems, I don't see the
problem described in the comment with the "dir" command on Windows XP
when I set this variable's value to zero.  And running DOS programs
from a w32 Emacs is much less probable use case these days, what with
the proliferation of 64-bit Windows systems that don't have a DOS
emulator.  So I think we can safely make this value zero or -1 on
modern systems.

Thanks for tracking this down.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]