From: Eli Zaretskii <eliz@gnu.org>
To: Stephen Leake <stephen_leake@stephe-leake.org>
Cc: 18626@debbugs.gnu.org
Subject: bug#18626: 24.3.94; communication with subprocess is slow
Date: Wed, 08 Oct 2014 16:53:12 +0300 [thread overview]
Message-ID: <837g0ak6rb.fsf@gnu.org> (raw)
In-Reply-To: <85ppe2vgdk.fsf@stephe-leake.org>
> 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.
next prev parent reply other threads:[~2014-10-08 13:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-04 6:47 bug#18626: 24.3.94; communication with subprocess is slow stephen_leake
2014-10-04 8:07 ` Eli Zaretskii
2014-10-05 13:20 ` Stephen Leake
2014-10-05 13:41 ` Stephen Leake
2014-10-05 14:43 ` Eli Zaretskii
2014-10-05 18:19 ` Stephen Leake
2014-10-04 8:11 ` Stephen Leake
2014-10-04 8:32 ` Eli Zaretskii
2014-10-04 22:29 ` Stefan Monnier
2014-10-05 2:46 ` Eli Zaretskii
2014-10-05 13:34 ` Stephen Leake
2014-10-05 14:40 ` Eli Zaretskii
2014-10-05 18:25 ` Stephen Leake
2014-10-05 19:04 ` Eli Zaretskii
2014-10-08 13:29 ` Stephen Leake
2014-10-08 13:53 ` Eli Zaretskii [this message]
2014-10-10 8:07 ` Stephen Leake
2014-10-10 9:13 ` Eli Zaretskii
2014-10-10 8:47 ` Stephen Leake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837g0ak6rb.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=18626@debbugs.gnu.org \
--cc=stephen_leake@stephe-leake.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).