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: Fri, 26 Jul 2019 23:38:46 -0400 Message-ID: <87o91guoxl.fsf@gmail.com> References: <87r4ltpctd.fsf@wallace.tews.net> 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="119925"; 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 Sat Jul 27 05:39:15 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 1hrDY8-000V0m-KI for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jul 2019 05:39:12 +0200 Original-Received: from localhost ([::1]:44076 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrDY7-0000mH-3Y for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Jul 2019 23:39:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56435) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrDY3-0000m9-NI for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 23:39:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hrDXy-0000AZ-Jo for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 23:39:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34699) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hrDXy-00007d-5D for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 23:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hrDXy-0002ry-0e for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 23:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Jul 2019 03:39: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.156419873711019 (code B ref 13400); Sat, 27 Jul 2019 03:39:01 +0000 Original-Received: (at 13400) by debbugs.gnu.org; 27 Jul 2019 03:38:57 +0000 Original-Received: from localhost ([127.0.0.1]:43520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrDXs-0002rf-OB for submit@debbugs.gnu.org; Fri, 26 Jul 2019 23:38:57 -0400 Original-Received: from mail-io1-f44.google.com ([209.85.166.44]:36751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrDXq-0002rS-Fu for 13400@debbugs.gnu.org; Fri, 26 Jul 2019 23:38:55 -0400 Original-Received: by mail-io1-f44.google.com with SMTP id o9so5252317iom.3 for <13400@debbugs.gnu.org>; Fri, 26 Jul 2019 20:38:54 -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=o64C6wZ4Zm2C+oAxuaFNQdm5vLtwZWbJH8K8GbAo8Uo=; b=kbSVo2WqmTYGL6IjIukDgG7MOt4Mo7o+PP4VFrnCDWoRFzcFR0o+7qlcrC/xZzPyrd /V88Jz933frUXVhSaBI1kwAn1PVxbh/1rcxj/sWg/MdopsFpw0Cwjyh8ARz6np34n5HR /5R8SX3VN9B7RDYjIaJyfHtQ5RDAWqWdny9fVqg+YrcFukO6q4H8KHJxNGjhdKUMHEDS IiHwkAiT1Hv0FWrbUwtt8Gr/YCGD+elkeStN9fdYpPT8ix1cZIxtUZB6sbSsNNdIVwp0 9Zh8o7jTEWUvlelC7d3e61NDF7717YwUKQpkToEv2erJGRoyTVTcv8Kg1KIQWQr+yAkz RgMw== 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=o64C6wZ4Zm2C+oAxuaFNQdm5vLtwZWbJH8K8GbAo8Uo=; b=EZq5Rr/GEDYzNmDlUhOKxJdFidQEkiY+/d2ynDIFoAinw1+kfKuCSONCsI17ilIBWy pfwT9VG6F/a7Dd/ge2+pKUd8OWxu4RbMSCNowZiPS0urVY9c1FynHTGc3Fn2yS4PZ2pM IydgXWMI5zhp3INHFeGBLa9iThiHOEGYUPSSPVEptHAQWFrRNwaPaUieHI7uTJIoQJgz siqQE575reFLJ4toTWOiEsV8S/sXeYMhn9ye5GH4prabE/ZrVc5b7fkm8k1BszZVDzoe jisDi+ZoSzfUB2EUflGXejwUWL8nI+595ILYrsIdGYOn5ql2K/uPng0Gm54VJ+CRIv28 XpqQ== X-Gm-Message-State: APjAAAUMSzGa0fUKOwnIjPLOqUnX2WaesesUEfTo2ojxxNTlHD3CJFj2 eDEpKRoqHPkHcZ9ax2Baxy8= X-Google-Smtp-Source: APXvYqz+WAUJsSMOk3xhZWJ0m6bq2FJSSz4KOxFhJv0V/niE98gl0+Apn2nmnz58ul+E0IaKkPHZ9g== X-Received: by 2002:a6b:e60b:: with SMTP id g11mr94653456ioh.9.1564198728790; Fri, 26 Jul 2019 20:38:48 -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 t133sm83275709iof.21.2019.07.26.20.38.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Jul 2019 20:38:47 -0700 (PDT) In-Reply-To: <87r4ltpctd.fsf@wallace.tews.net> (Hendrik Tews's message of "Thu, 10 Jan 2013 11:11:42 +0100") 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:163821 Archived-At: --=-=-= Content-Type: text/plain 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. > - Same in "37.9.2. Process Filter Functions" This section is repeated twice (I addressed the second instance below). > - 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. > - "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. > - "37.9.2 Process Filter Functions" ignores the problem > completely. There should be a paragraph clearly stating this > problem. Further, it would be nice, if the filter function > example could be extended to correctly deal with this problem. I added a mention of the possibility of recursion. I'm not sure about making an example (specifically, what is the best way to deal with this problem?). --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=0001-Note-that-process-filter-can-be-called-recursively-B.patch Content-Description: patch >From 022fb3f287d4fd351078f2b134d187ff584b380c 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 (Output from Processes): Note that functions which send data may also trigger reading from processes. (Filter Functions): Note that filter functions may be called recursively. --- doc/lispref/processes.texi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi index a93f4db428..208005772e 100644 --- a/doc/lispref/processes.texi +++ b/doc/lispref/processes.texi @@ -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 @@ -1683,6 +1684,10 @@ Filter Functions or more batches of output; one way to do this is to insert the received text into a temporary buffer, which can then be searched. +Note that if the filter calls a function which can wait for process +output (pxref{Output from Processes}), the filter may be called +recursively. + @defun set-process-filter process filter This function gives @var{process} the filter function @var{filter}. If @var{filter} is @code{nil}, it gives the process the default filter, -- 2.11.0 --=-=-= Content-Type: text/plain > To make it easier in the future to deal with this problem, I > suggest to add a process specific flag > ``process-no-concurrent-filters''. When this flag is t for a > process, Emacs accepts output from this process inside a filter > but buffers it without calling the filter. The call to the filter > is delayed until a point where no filter for this process is > running. An error is signaled, if the buffered output exceeds a > certain size. I thought of just making a wrapper in Lisp instead, this saves the need to complicate the process C code with yet another flag; it's already tricky enough as it is. ;;; -*- lexical-binding: t -*- (defun make-buffered-filter (filter) (let ((filtering nil) (buffered nil) (process nil)) (lambda (proc str) (if process (unless (eq process proc) (error "Buffered filter used in different processes: %S, %S" proc process)) (setq process proc)) (push str buffered) (unless filtering (setq filtering t) (unwind-protect (while buffered (setq str (apply #'concat (nreverse buffered))) (setq buffered nil) (funcall filter proc str)) (setq filtering nil)))))) ;; Can be used like (set-process-filter my-process (make-buffered-filter #'my-filter-function)) --=-=-=--