From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#13400: 23.4; overlapping process filter calls Date: Wed, 07 Aug 2019 21:15:49 -0400 Message-ID: <874l2ssbi2.fsf@gmail.com> References: <87r4ltpctd.fsf@wallace.tews.net> <87o91guoxl.fsf@gmail.com> <87wofr1bog.fsf@cert.kernkonzept.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="174923"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) Cc: 13400@debbugs.gnu.org, Stefan Monnier To: Hendrik Tews Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 08 03:16:16 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 1hvX2O-000jO9-An for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Aug 2019 03:16:16 +0200 Original-Received: from localhost ([::1]:46300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvX2M-0007Ot-NI for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Aug 2019 21:16:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45948) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvX2H-0007Oa-8f for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2019 21:16:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvX2F-0008PU-Om for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2019 21:16:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59132) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvX2F-0008PQ-Jh for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2019 21:16:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hvX2F-0001OH-EK for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2019 21:16:07 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2019 01:16:07 +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.15652269605304 (code B ref 13400); Thu, 08 Aug 2019 01:16:07 +0000 Original-Received: (at 13400) by debbugs.gnu.org; 8 Aug 2019 01:16:00 +0000 Original-Received: from localhost ([127.0.0.1]:39718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hvX27-0001NS-Ps for submit@debbugs.gnu.org; Wed, 07 Aug 2019 21:16:00 -0400 Original-Received: from mail-ot1-f52.google.com ([209.85.210.52]:34308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hvX26-0001NG-KR for 13400@debbugs.gnu.org; Wed, 07 Aug 2019 21:15:59 -0400 Original-Received: by mail-ot1-f52.google.com with SMTP id n5so112115229otk.1 for <13400@debbugs.gnu.org>; Wed, 07 Aug 2019 18:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=MO8PU3Lj4N2c7DTrwby8WSAH4ifGssLb5p7+SVP6LA0=; b=ojMROmNWQhxhJDNpSnowR8KJ2FPAH7qvHHTq+3gis7d/7zv4XnxF1CYF/EFpIHnX+A zQM+v0cCE1wSS+jm3WpknynPJ58f/G9ObxYxBlGfZ2qVVLmuIt1jmF1NdvW7qReFqWFe cF81FpwSluWttj05jRrUat06/+lKQmFCnE12rDVqse9Yc8irAY1deperGPA70IYnog40 Ny6B6BOdLMvvpR2fWyVYteiFt0ENyzONz7b3WTOQGLaRXp5LDzbPykfFstbDi9bt8XRe LYocYwa69QSt5zOP0AUe0QpsEhFor/mp7pDqbWibMLEMJNFiLFBrJEG0wih/TkCHp30y NW8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=MO8PU3Lj4N2c7DTrwby8WSAH4ifGssLb5p7+SVP6LA0=; b=r/VOZqBQdXGJ+sLYdOwuERuhLTY8GNzdRb5HolkfMJL3oNXwbi7qIIaijbJyW+HnDO yj0GFG5F3mIGhKf0WEgzcWBGKkZBcj4D58Zjvf30ucMngfjUGpEpf5I/D5WSfDwVnqAo qrzgA7QBk+YdC8lbrvhOXrVWd0LWdzeEd4rW8J3qUI2Ytfntvj8Vf8r0qUalZzNbSst1 5ENR9bC55S461OVhNbFaV2f1pb71cn/VmDazLZdw+CWBbyMaaCvP8FMDMMDylpJ4IpN/ 0K8YcYh/6ZoahlF70plFqXo2v5MlIc043QJciUeMMSK31kHPkdsByvP1Mp73n3OzuGNJ y58A== X-Gm-Message-State: APjAAAVofeAuv8/kQUk0aZOVLAXthbYvoApdcoyq8UnnGyvUNdUSlzpW KYu8RcGly1164dAiglU/0L8= X-Google-Smtp-Source: APXvYqxcTvajEnAeSTiwdZHdrQRiJeJ5Hg52NZ9TtPro9QM+JpcLMGWZifz4IYleuHcD5UOkvEk6qg== X-Received: by 2002:a6b:6f17:: with SMTP id k23mr439873ioc.25.1565226951910; Wed, 07 Aug 2019 18:15:51 -0700 (PDT) Original-Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id c13sm606085iok.84.2019.08.07.18.15.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Aug 2019 18:15:50 -0700 (PDT) In-Reply-To: <87wofr1bog.fsf@cert.kernkonzept.com> (Hendrik Tews's message of "Tue, 06 Aug 2019 00:37:19 +0200") 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:164740 Archived-At: --=-=-= Content-Type: text/plain Hendrik Tews writes: > thanks for addressing this quite old bug report. I do have some > comments: Thanks for still following up even though the reply was so delayed. >>> - 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? As far as I know, all the blocking functions are listed in the Input to Processes node which I xref'd. >>> - 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. Aha, missed that, thanks. >>> - 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, Thanks, it's hard to pick out such details on the Nth time reading the manual. >>> - "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 I'm just not sure anyone is going to notice such details when it really matters. In my experience the manual is more about having something authoritative to point to when folks ask "why does X happen?". But I've added a parenthetical to the patch. > 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. Yes, hence the xrefs. See attached updated patch. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=0001-Note-that-process-filter-can-be-called-recursively-B.patch Content-Description: patch >From 895b3e135828006732bde40d54f74b1d5d3957f2 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Fri, 26 Jul 2019 23:20:37 -0400 Subject: [PATCH] Note that process filter can be called recursively (Bug#13400) * doc/lispref/processes.texi (Asynchronous Processes): Note that input may read when sending data as well. (Output from Processes): Note that functions which send data may also trigger reading from processes. (Input to Processes, Filter Functions): Note that filter functions may be called recursively. --- doc/lispref/processes.texi | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi index a93f4db428..bd807cdcee 100644 --- a/doc/lispref/processes.texi +++ b/doc/lispref/processes.texi @@ -588,9 +588,8 @@ Asynchronous Processes parallel with Emacs, and Emacs can communicate with it using the functions described in the following sections (@pxref{Input to Processes}, and @pxref{Output from Processes}). Note that process -communication is only partially asynchronous: Emacs sends data to the -process only when certain functions are called, and Emacs accepts data -from the process only while waiting for input or for a time delay. +communication is only partially asynchronous: Emacs sends and receives +data to and from a process only when those functions are called. @cindex pty, when to use for subprocess communications @cindex pipe, when to use for subprocess communications @@ -1200,8 +1199,9 @@ Input to Processes because the input buffer is full. When this happens, the send functions wait a short while, accepting output from subprocesses, and then try again. This gives the subprocess a chance to read more of its pending -input and make space in the buffer. It also allows filters, sentinels -and timers to run---so take account of that in writing your code. +input and make space in the buffer. It also allows filters (including +the one currently running), sentinels and timers to run---so take +account of that in writing your code. In these functions, the @var{process} argument can be a process or the name of a process, or a buffer or buffer name (which stands @@ -1416,9 +1416,10 @@ Output from Processes Output from a subprocess can arrive only while Emacs is waiting: when reading terminal input (see the function @code{waiting-for-user-input-p}), -in @code{sit-for} and @code{sleep-for} (@pxref{Waiting}), and in -@code{accept-process-output} (@pxref{Accepting Output}). This -minimizes the problem of timing errors that usually plague parallel +in @code{sit-for} and @code{sleep-for} (@pxref{Waiting}), in +@code{accept-process-output} (@pxref{Accepting Output}), and in +functions which send data to processes (@pxref{Input to Processes}). +This minimizes the problem of timing errors that usually plague parallel programming. For example, you can safely create a process and only then specify its buffer or filter function; no output can arrive before you finish, if the code in between does not call any primitive @@ -1594,14 +1595,10 @@ Filter Functions By default, the error output from the process, if any, is also passed to the filter function, unless the destination for the standard error stream of the process was separated from the standard output -when the process was created (@pxref{Output from Processes}). - - The filter function can only be called when Emacs is waiting for -something, because process output arrives only at such times. Emacs -waits when reading terminal input (see the function -@code{waiting-for-user-input-p}), in @code{sit-for} and -@code{sleep-for} (@pxref{Waiting}), and in -@code{accept-process-output} (@pxref{Accepting Output}). +when the process was created. Emacs will only call the filter +function during certain function calls. @xref{Output from Processes}. +Note that if any of those functions are called by the filter, the +filter may be called recursively. A filter function must accept two arguments: the associated process and a string, which is output just received from it. The function is -- 2.11.0 --=-=-=--