bug#18626: 24.3.94; communication with subprocess is slow

[Stephen Leake <stephen_leake@stephe-leake.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

That has essentially no effect when running on a multi-core machine; the
subprocess is scheduled separately.

> 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.

Ok.

> Thanks for tracking this down.

You're welcome. Thanks for your work on Emacs for Windows!

-- 
-- Stephe