From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: process_send_string blocks? Date: Sat, 06 Sep 2014 12:34:04 +0300 Message-ID: <83r3zpcctv.fsf@gnu.org> References: <85y4txdvbh.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409996075 22054 80.91.229.3 (6 Sep 2014 09:34:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2014 09:34:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 06 11:34:28 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQCO4-0003PO-Ir for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2014 11:34:28 +0200 Original-Received: from localhost ([::1]:33909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQCO4-0003Lr-7U for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2014 05:34:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQCNn-0003K3-5y for emacs-devel@gnu.org; Sat, 06 Sep 2014 05:34:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQCNg-0002ko-To for emacs-devel@gnu.org; Sat, 06 Sep 2014 05:34:11 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:42918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQCNg-0002ki-HX for emacs-devel@gnu.org; Sat, 06 Sep 2014 05:34:04 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NBH004003MKZD00@mtaout26.012.net.il> for emacs-devel@gnu.org; Sat, 06 Sep 2014 12:32:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBH0046Q3TEKN10@mtaout26.012.net.il>; Sat, 06 Sep 2014 12:32:02 +0300 (IDT) In-reply-to: <85y4txdvbh.fsf@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174055 Archived-At: > From: Stephen Leake > Date: Sat, 06 Sep 2014 03:09:22 -0500 > > I'm trying to use a background process to parse buffer text, and send > results back to Emacs. > > For large buffers, Emacs hangs; only killing the background process > externally recovers. This does not happen for small buffers (< 5k bytes?). > > It appears that process-send-string is blocked on a full IO send queue, > while the background process is also blocked on a full IO send queue. Please tell the details of how did you determine this. > On reading process.c, I believe this should not happen, if the OS supports > EWOULDBLOCK. > > Is that true, even when there is only one call to process-send-string that > sends the entire buffer? Not sure what are you asking here, since you say you've read the code and saw the handling of EWOULDBLOCK. > I'm running on Windows 7, using the Windows binary > emacs-23.4-bin-i386.zip from the FSF FTP site. > > Is EWOULDBLOCK supported on this system? Not on writes to pipes, AFAIK. > I'll try compiling Emacs from source so I can run the debugger; I've > never tried that on Windows before. Please do that with the latest pretest, as 24.3 is by now ancient history. Also, I suggest to use the latest version 7.8 of GDB, which you can find here: http://sourceforge.net/projects/ezwinports/files/?source=navbar (Please be sure to read the instructions on the download page, near its end, which also appear in README.txt, about setting Guile- and Python-related environment variables.) To get you up to speed: each subprocess has a dedicated reader thread; see w32proc.c:reader_thread. That thread attempts to read 1 byte from the pipe, and if succeeded, it uses an event object to communicate to the main (a.k.a. "Lisp") thread that it has read something; sys_select should then see that and tell the main thread it can read from the pipe. It then waits for acknowledge from the main thread before it attempts to read more. Writing to the pipe is implemented in w32.c:sys_write (the calls to 'write' elsewhere in Emacs are redirected there). This runs in the context of the main thread. The buffer size for the pipe is defined in w32.c:pipe2. We pass zero to the _pipe function, which means "use the default buffer size". I couldn't find any information about that default, but you could try using some specific sizes there (make them integral multiples of 16K) and see if that makes any difference in your situation. The first thing I'd do is attach GDB to the hung Emacs and see where each one of these 2 threads is parked. (Note that there are more threads in a running Emacs than just these 2.) Finally, it is better to continue all this on the bug tracker, perhaps as part of bug #18396, or a new bug report, if you don't want to mix up these 2.