From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Fix for slow process output processing (please test). Date: 05 Jan 2004 20:39:53 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87y8so7kjy.fsf@offby1.atm01.sea.blarg.net> <2914-Mon05Jan2004210950+0200-eliz@elta.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073332338 8854 80.91.224.253 (5 Jan 2004 19:52:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2004 19:52:18 +0000 (UTC) Cc: offby1@blarg.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jan 05 20:52:14 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Adalq-0008Kk-00 for ; Mon, 05 Jan 2004 20:52:14 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Adalq-0005U3-00 for ; Mon, 05 Jan 2004 20:52:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Adban-0001re-OK for emacs-devel@quimby.gnus.org; Mon, 05 Jan 2004 15:44:53 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdbYX-0001JX-KT for emacs-devel@gnu.org; Mon, 05 Jan 2004 15:42:33 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdbY0-0001CG-Ji for emacs-devel@gnu.org; Mon, 05 Jan 2004 15:42:31 -0500 Original-Received: from [217.80.160.71] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AdbXz-0001Ae-RJ for emacs-devel@gnu.org; Mon, 05 Jan 2004 15:42:00 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i05Je188009568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2004 20:40:01 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i05Jdrop009564; Mon, 5 Jan 2004 20:39:53 +0100 Original-To: Eli Zaretskii In-Reply-To: <2914-Mon05Jan2004210950+0200-eliz@elta.co.il> Original-Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19021 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19021 "Eli Zaretskii" writes: > > From: David Kastrup > > Date: 05 Jan 2004 16:57:14 +0100 > > > > > > I suppose that process-adaptive-read-buffering isn't really needed > > > on Windows, > > > > Since Windows is slow, anyway? > > I think the reason is that Windows never feeds Emacs with such small > chunks from a pipe. > > > I suppose the problem could be that the Windows equivalent of > > "select" that Emacs uses does a busy wait without yielding the > > CPU. > > I think that's not true: it does yield the CPU. See > w32proc.c:sys_select. More exactly: my guess is that the equivalent may yield the CPU to the operating system, but the operating system may be of the opinion that it will prefer to use up short delay slots by an active wait rather than letting other processes run. In short: it is my suspicion that the yielded CPU time does not arrive at the intended place. You could not know this from Emacs sources, however. We'd need somebody with Windows insights to get more of a clue. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum