From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Hendrik Tews Newsgroups: gmane.emacs.bugs Subject: bug#13400: 23.4; overlapping process filter calls Date: Tue, 06 Aug 2019 00:37:19 +0200 Message-ID: <87wofr1bog.fsf@cert.kernkonzept.com> References: <87r4ltpctd.fsf@wallace.tews.net> <87o91guoxl.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="236696"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 13400@debbugs.gnu.org, Stefan Monnier To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 06 00:38:08 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hulcG-000zRI-EV for geb-bug-gnu-emacs@m.gmane.org; Tue, 06 Aug 2019 00:38:08 +0200 Original-Received: from localhost ([::1]:57338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hulcF-0008Sw-HF for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Aug 2019 18:38:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50553) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hulcB-0008So-FH for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2019 18:38:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hulcA-0000od-40 for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2019 18:38:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55419) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hulcA-0000oY-0t for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2019 18:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hulc9-0000hE-RS for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2019 18:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Hendrik Tews Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Aug 2019 22:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13400 X-GNU-PR-Package: emacs Original-Received: via spool by 13400-submit@debbugs.gnu.org id=B13400.15650446512635 (code B ref 13400); Mon, 05 Aug 2019 22:38:01 +0000 Original-Received: (at 13400) by debbugs.gnu.org; 5 Aug 2019 22:37:31 +0000 Original-Received: from localhost ([127.0.0.1]:36007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hulbf-0000gR-03 for submit@debbugs.gnu.org; Mon, 05 Aug 2019 18:37:31 -0400 Original-Received: from askra.de ([81.169.225.145]:49850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hulbd-0000gJ-P3 for 13400@debbugs.gnu.org; Mon, 05 Aug 2019 18:37:30 -0400 Original-Received: from ip5f5a9926.dynamic.kabel-deutschland.de ([95.90.153.38] helo=cert) by askra.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hulba-0003yN-4F; Tue, 06 Aug 2019 00:37:26 +0200 Original-Received: from localhost ([::1] helo=cert) by cert with esmtp (Exim 4.92) (envelope-from ) id 1hulbU-0008LB-F2; Tue, 06 Aug 2019 00:37:20 +0200 In-Reply-To: <87o91guoxl.fsf@gmail.com> (Noam Postavsky's message of "Fri, 26 Jul 2019 23:38:46 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:164659 Archived-At: Noam, thanks for addressing this quite old bug report. I do have some comments: Noam Postavsky writes: > Hendrik Tews writes: > >> because Stefan Monnier asked for it >> (http://lists.inf.ed.ac.uk/pipermail/proofgeneral-devel/2013/000296.html) > > [Note: meanwhile the section number has changed to 38 instead of 37.] > >> - Section "37.9 Receiving Output from Processes" does not list >> process-send-string. How about other blocking I/O functions? > > In the attached patch, I've added a mention/xref for functions which send > data to processes. How about other blocking I/O functions? When output is accepted inside process-send-string, then it probably is in all potentially blocking I/O functions? The list of functions in 38.9 after "Output from a subprocess can arrive only" should be complete. If the programmer cannot rely on the documentation to be complete here, he or she has no other choice than to assume that output can arrive anywhere and he/she _is_ plagued with the usual parallel programming problems. Therefore, please make a careful investigation to ensure that the list of functions in which output can arrive is _really_ complete in the documentation. >> - Same in "37.9.2. Process Filter Functions" > > This section is repeated twice (I addressed the second instance below). I mentioned this section twice, because there are _two_ documentation problems. I really believe you should address both and not just one. The first problem in 38.9.2 is the same as above: The list of functions after "The filter function can only be called" is far from complete. The second problem is that it does not document the possibility of recursive filter calls. >> - Same in "37.4 Creating an Asynchronous Process" , >> process-send-string is neither waiting for input not time >> delay. > > I don't see any mention of process-send-string in that section, nor how > it's relevant to the rest of this report. Come on, please read that section carefully. "Emacs accepts data from the process only while waiting for input or for a time delay" in there implies that Emacs is _not_ accepting data during process-send-string, because, as I wrote, >> process-send-string is neither waiting for input no[r] time >> delay. Therefore, this section implies that Emacs is _not_ accepting data during process-send-string. If it does, it is a bug. >> - "37.7 Sending Input to Processes" says that filters can run >> inside process-send-string, but it could be clearer about the >> point that this can also happen inside the same filter for the >> same process. > > I'm not really convinced that is necessary. It is about a few words making the documentation more precise, potentially saving somebody a painful debugging session of several hours - similar to what I went through in 2013. Back then, I was lucky because clearing the disk caches was enough to reproduce the problem. Today with SSD's it is probably much harder... Adding to the original bug report, I would suggest to restructure the documentation, such that there is only one section documenting all the functions in which process output could arrive and such that all the other sections only refer to that section. It should really not be the case that different sections make different and sometimes inconsistent statements about the same feature. Hendrik