Received: (at 13400) by debbugs.gnu.org; 20 Aug 2019 12:19:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 20 08:19:26 2019 Received: from localhost ([127.0.0.1]:60951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1i036k-0007q3-Lj for submit <at> debbugs.gnu.org; Tue, 20 Aug 2019 08:19:26 -0400 Received: from mail-io1-f48.google.com ([209.85.166.48]:43522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <npostavs@HIDDEN>) id 1i036i-0007po-Sv for 13400 <at> debbugs.gnu.org; Tue, 20 Aug 2019 08:19:25 -0400 Received: by mail-io1-f48.google.com with SMTP id 18so11625525ioe.10 for <13400 <at> debbugs.gnu.org>; Tue, 20 Aug 2019 05:19:24 -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=ib9qraq4Ect+BhUNYIuYn3pGO2QzVDpHiS1GkdvaZ7Y=; b=lkhtf0Mx+Vtrlxj/LLvHQgSrcs0bBH9ba4rVte4+luZQWT1/DuC+MphhLc1RAF0aWL AwJhUbyWpyiVpqaq/vla5hSdtNkASfLoKJQIzTKpaT/rJq+cY05AiXbTt5EOlIEqiePh ad5KlPgfWj86PNSZVaQmG2KGJ3jg8dvbUhM4Y/0XymvCmmiIXWst2GiuvBSqkwZtKeW1 mUNNb1/vgbO65NKMCoopggCKaNtgb+TFeIn5waYOnaVjh1gdjYKpxzBOa98pLG6IEwfl FBgY5sLsc2qdM6Z5R6HdDCeRUUOXkdfYl8askdqWRGzoQtbZRGdBhXla0alf0nhAQmsl tFIg== 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=ib9qraq4Ect+BhUNYIuYn3pGO2QzVDpHiS1GkdvaZ7Y=; b=qyc8ERN90m6uKcDH0mTNFTpOi1fkTobHJ2K/3KMd6UBhPrczcGTTEExU+NlFbhvOjN Mhfepf7J14Zag6g0LvqZXNSavR5mSuTkUu4I1mzG66RJqR6G4wZI9gSE0Ta2uFSlRX7E 7zve7NLS2JS64rq1Kgm9YXmmj7Srju3pXq18+zPc0E0JO29TuIttOVb9og++/b+kmJPS 7T89Q2rZV2p7SqQa2+/RoaYpVwcAjdzwukL/vClYAml8gVvnfpX41o1xwixVpH7vC5Il rVd5/UBAdDt9jEJHHkS4gKHg2CygQ/IDNGEIW+TO4dpZIuZZFlAVt3QwAeDiliXo/XJC nRIw== X-Gm-Message-State: APjAAAXIRqky9So8VAbUxWBKxJkRoKZ+yBNAxfnCbmzlvuBcCUPB+NVN BqpMjp9rkiUxhecQnkorNgg= X-Google-Smtp-Source: APXvYqzZeF459yZBRsCK5zV8htlHj5fAp4FeereHQ8xgpbilGK7XR5kSltvby4zGaJSuCFJNRM9Mwg== X-Received: by 2002:a6b:8b47:: with SMTP id n68mr405917iod.191.1566303559377; Tue, 20 Aug 2019 05:19:19 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id r7sm14777124ioa.71.2019.08.20.05.19.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Aug 2019 05:19:18 -0700 (PDT) From: Noam Postavsky <npostavs@HIDDEN> To: Hendrik Tews <hendrik@HIDDEN> Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> <87wofr1bog.fsf@HIDDEN> <874l2ssbi2.fsf@HIDDEN> Date: Tue, 20 Aug 2019 08:19:17 -0400 In-Reply-To: <874l2ssbi2.fsf@HIDDEN> (Noam Postavsky's message of "Wed, 07 Aug 2019 21:15:49 -0400") Message-ID: <87v9usni62.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13400 Cc: 13400 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > See attached updated patch. I've pushed it to emacs-26. Leaving the bug open for now, since we might still want to actually change the behaviour. 615cff4258 2019-08-19T19:49:50-04:00 "Fix process filter documentation (Bug#13400)" https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=615cff42580a3521c1a4ea7c3ec467eb8259e1c7
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at 13400) by debbugs.gnu.org; 10 Aug 2019 09:03:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 10 05:03:42 2019
Received: from localhost ([127.0.0.1]:43453 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1hwNHp-00069I-QR
for submit <at> debbugs.gnu.org; Sat, 10 Aug 2019 05:03:42 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34458)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1hwNHo-000695-4o
for 13400 <at> debbugs.gnu.org; Sat, 10 Aug 2019 05:03:40 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B1C9F85AFB;
Sat, 10 Aug 2019 05:03:34 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 99A448123C;
Sat, 10 Aug 2019 05:03:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1565427813;
bh=h4NNoJPSy5367VAOqooCZiUr9Ktv9OiPSfbLIk4X2Kc=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=dayXziXsnyj1TdkAUjQwTA2laOcLX37/0o3j82n+3PilHP//FTMm8++b3snVIibH8
hlB4ALnUsC45kFAYf231hSbl7aJo+WoJCm03SqFeMU8JtxvJq25loSw+Y6g3JEBsm9
pFj+NRe9gSbo2SoI+JdW6eqq9lrlwTyZ1a0jvQ5fXr/dP0jA9KfHiE2gpdRkZCqlYR
HnTp0j8/fjeTd9dIS6C3X8QZPEMK5Pv+szTS8kfT8DchSVvkwLdyvkmW3OL8EyYPa+
h4wwyMrIyAJzsVAevnkkH+uOJix3hulLhBk+PQG0vFS5DurqQuYQTqGN+aFy4+ThYg
fw+AChXpzGwGw==
Received: from alfajor (dyn.83-228-179-131.dsl.vtx.ch [83.228.179.131])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1ED07120995;
Sat, 10 Aug 2019 05:03:31 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Noam Postavsky <npostavs@HIDDEN>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Message-ID: <jwvef1tcs9z.fsf-monnier+emacs@HIDDEN>
References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN>
<835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN>
<jwvv9vbii0c.fsf-monnier+emacs@HIDDEN> <871rxws4xy.fsf@HIDDEN>
<83a7cjbwyz.fsf@HIDDEN> <jwv7e7mdntp.fsf-monnier+emacs@HIDDEN>
<878ss1re7v.fsf@HIDDEN>
Date: Sat, 10 Aug 2019 05:03:24 -0400
In-Reply-To: <878ss1re7v.fsf@HIDDEN> (Noam Postavsky's message of "Fri, 09
Aug 2019 21:39:16 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 13400
Cc: Eli Zaretskii <eliz@HIDDEN>, 13400 <at> debbugs.gnu.org, hendrik@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> That sounds like it would equivalent to setting the process' filter
> function to t while running its body.
Yes.
> If you try that with the example in the OP, you get a deadlock,
> because the subprocess' pipe becomes full as Emacs stops reading it,
> and its input pipe becomes full so Emacs gets stuck when trying to
> send data to it.
Indeed. It's a classic problem with popen-like setups.
It's a problem if Emacs itself gets stuck preventing other things to
run, but otherwise I don't see it as a real problem: the OP's example
is artificial.
> I thought you meant something more like my make-buffered-filter example,
> where Emacs would still read from the process, but not call the filter
> function with the new data until the current invocation ends (i.e.,
> Emacs would just temporarily save the data).
That's another option.
Stefan
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 10 Aug 2019 01:39:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 09 21:39:26 2019 Received: from localhost ([127.0.0.1]:43356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hwGLu-0003CM-75 for submit <at> debbugs.gnu.org; Fri, 09 Aug 2019 21:39:26 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:34133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <npostavs@HIDDEN>) id 1hwGLs-0003By-8Q for 13400 <at> debbugs.gnu.org; Fri, 09 Aug 2019 21:39:24 -0400 Received: by mail-ot1-f68.google.com with SMTP id n5so139785924otk.1 for <13400 <at> debbugs.gnu.org>; Fri, 09 Aug 2019 18:39:24 -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=d4i6ChjO6Fd9zJFhVNtv0sLLfdVctcLf/4o1ljOLKhY=; b=JG/JPsPfCH3V22x0ZrXkFcDhDt9kXVCe7PKQMtS6mjuwWFv06cDPWtZwypRaCRNByj DTvSCqcMOOScNcuGUadXCtWf+rK7BqpR5EYVKg0qCw6vG5MUD3cCQFi95uF79VYrNNK+ wJhEu+s6/Zofh7/NuRI+L+P5r9NBKE4bvUuNYOSWpt24wAeEtr9SFsfIqUCPCAwczktb /O9S1g22X9WEY4CaxP1V0I10zJ4H5yBDhzUK/jtmWZFgoOuu0qb4ILIMY9bh/2r595yh SjWA4Wl76WLPGJtq8wUiNT5j6d3uNpr8kH6JbKmAAvl7ZLAFjKihm088BBE+xDkY3qoL BFGg== 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=d4i6ChjO6Fd9zJFhVNtv0sLLfdVctcLf/4o1ljOLKhY=; b=CMujG1a9RpiVrs7wrWfThsDLLlDXYMKCo0yqPHKExT2Uc8dW/zYmkNsi6r2ruMdKWX NMU9MD8PFeL7KSsmIJYLE8Ft2x5rXQ/euH8Ynn93lGfbYw24KlWsksKSV2b/x8LJQqs/ zHwQN2rIXGgW9orY6CAbgmaEyjbgfXsUH7rsF3tRa9ZkwnYbURgrRHUTB3ObAOkrtWk6 BM2oEqTGMhgruUZbcewzFmwhqCzlG7RzAWc9fCOzWqFYSUPROjQ5r9U5z75y4FmO6kQa IBq9Af7VPxBqkZoYFauao29Xfm+OO+q3C4AvT2j5UfJgzOYjtUEZKEGI5Cio2MYyqX2j vZXQ== X-Gm-Message-State: APjAAAWwwuVLaxCjw3l7jdVDcplUAT5VXV5MfEDEgfeM0OFzb+L8ey/W Rse3Nm4O2FnTIQ8kYlnB6UDBtneR X-Google-Smtp-Source: APXvYqzV2M0vS4MSHi+v26Fw05Qpd9t2cOIOiEcDiTFuhKl5PHXwpqsbtpm2UClbrKhaF1HyDj92OA== X-Received: by 2002:a5e:9314:: with SMTP id k20mr24898964iom.235.1565401158372; Fri, 09 Aug 2019 18:39:18 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id l2sm68739856ioh.20.2019.08.09.18.39.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Aug 2019 18:39:17 -0700 (PDT) From: Noam Postavsky <npostavs@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> <835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN> <jwvv9vbii0c.fsf-monnier+emacs@HIDDEN> <871rxws4xy.fsf@HIDDEN> <83a7cjbwyz.fsf@HIDDEN> <jwv7e7mdntp.fsf-monnier+emacs@HIDDEN> Date: Fri, 09 Aug 2019 21:39:16 -0400 In-Reply-To: <jwv7e7mdntp.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Fri, 09 Aug 2019 17:36:34 -0400") Message-ID: <878ss1re7v.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13400 Cc: Eli Zaretskii <eliz@HIDDEN>, 13400 <at> debbugs.gnu.org, hendrik@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: >> Hmm... I'm not sure I understand what would this mean in practice. >> Suppose a process filter invokes some blocking API, which then calls >> wait_reading_process_output, and 'pselect' tells us that same process >> can be read from again. > > I think we shouldn't pass that process's handle to pselect. That sounds like it would equivalent to setting the process' filter function to t while running its body. If you try that with the example in the OP, you get a deadlock, because the subprocess' pipe becomes full as Emacs stops reading it, and its input pipe becomes full so Emacs gets stuck when trying to send data to it. I thought you meant something more like my make-buffered-filter example, where Emacs would still read from the process, but not call the filter function with the new data until the current invocation ends (i.e., Emacs would just temporarily save the data).
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at 13400) by debbugs.gnu.org; 9 Aug 2019 21:36:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 09 17:36:49 2019
Received: from localhost ([127.0.0.1]:43315 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1hwCZ6-0004w9-Pc
for submit <at> debbugs.gnu.org; Fri, 09 Aug 2019 17:36:48 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22738)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1hwCZ4-0004vw-0T
for 13400 <at> debbugs.gnu.org; Fri, 09 Aug 2019 17:36:47 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 80E1B85AF7;
Fri, 9 Aug 2019 17:36:40 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EABEC81093;
Fri, 9 Aug 2019 17:36:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1565386599;
bh=Fk8tIUJ95AqgzTkfpskcwLcwfE07X5Pi95LTiEvSSUM=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=Db0Zksm3IFXd5X9nwmHdHB2sbFV3sVMehjklBxGgVXk5Z22HkykyIGHtUSPbFVWk0
oprnAT5/3JeJtrVjQrjOLMq5uBbH+XHpeFZZsUfqQU2gi+rDPRq1mILrzU9J/AECWc
kndUnLPbBoBGBzXH99b3qu5e4fTttEsVK+Z9toQclc2q2oFOfXcKITfvUs0BhHGCrP
TyKcKCXpTd0GqMTAMRcRkyN1k0hyH+stNsZ+0ThI9psWbEh9Ctrv6ogEVIgCeRiMVq
MctNhcEpJhuVOpT6+zI53Ixy0UbJJ4b/EMQ9ZuwrHv9z8dnS4pIZrbKwLXPseYxdWs
Fs+NyPKVDZeag==
Received: from alfajor (dyn.83-228-179-131.dsl.vtx.ch [83.228.179.131])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3AF01120C2D;
Fri, 9 Aug 2019 17:36:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Message-ID: <jwv7e7mdntp.fsf-monnier+emacs@HIDDEN>
References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN>
<835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN>
<jwvv9vbii0c.fsf-monnier+emacs@HIDDEN> <871rxws4xy.fsf@HIDDEN>
<83a7cjbwyz.fsf@HIDDEN>
Date: Fri, 09 Aug 2019 17:36:34 -0400
In-Reply-To: <83a7cjbwyz.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 08 Aug
2019 16:36:20 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 13400
Cc: hendrik@HIDDEN, 13400 <at> debbugs.gnu.org,
Noam Postavsky <npostavs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> Hmm... I'm not sure I understand what would this mean in practice.
> Suppose a process filter invokes some blocking API, which then calls
> wait_reading_process_output, and 'pselect' tells us that same process
> can be read from again.
I think we shouldn't pass that process's handle to pselect.
Stefan
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 8 Aug 2019 13:36:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 08 09:36:39 2019 Received: from localhost ([127.0.0.1]:40187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hviat-0000oh-Fn for submit <at> debbugs.gnu.org; Thu, 08 Aug 2019 09:36:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57399) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1hviap-0000oR-If for 13400 <at> debbugs.gnu.org; Thu, 08 Aug 2019 09:36:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1hviai-0003Ms-VT; Thu, 08 Aug 2019 09:36:29 -0400 Received: from [176.228.60.248] (port=2840 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1hviai-0004Pf-Bs; Thu, 08 Aug 2019 09:36:28 -0400 Date: Thu, 08 Aug 2019 16:36:20 +0300 Message-Id: <83a7cjbwyz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Noam Postavsky <npostavs@HIDDEN> In-reply-to: <871rxws4xy.fsf@HIDDEN> (message from Noam Postavsky on Wed, 07 Aug 2019 23:37:29 -0400) Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> <835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN> <jwvv9vbii0c.fsf-monnier+emacs@HIDDEN> <871rxws4xy.fsf@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 13400 Cc: hendrik@HIDDEN, 13400 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Noam Postavsky <npostavs@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 13400 <at> debbugs.gnu.org, hendrik@HIDDEN > Date: Wed, 07 Aug 2019 23:37:29 -0400 > > > So the default should be to prevent it, with maybe some way to override > > it to cater to the exceptional case where recursive invocation > > is to be allowed. > > > > I think we could do that by setting a property on process object during > > filter invocation to postpone further filter invocations, and then the > > process filter could locally unset this property if it wants to allow > > recursive invocations. > > Yeah, I suppose that would probably be better. Although then we have > some potential weird edge cases like what happens when when changing the > property during a recursive invocation. Hmm... I'm not sure I understand what would this mean in practice. Suppose a process filter invokes some blocking API, which then calls wait_reading_process_output, and 'pselect' tells us that same process can be read from again. How will we avoid calling the filter recursively in this case, and what will we do instead of calling it?
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 8 Aug 2019 03:37:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 07 23:37:38 2019 Received: from localhost ([127.0.0.1]:39750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hvZFC-0006nq-6u for submit <at> debbugs.gnu.org; Wed, 07 Aug 2019 23:37:38 -0400 Received: from mail-ot1-f53.google.com ([209.85.210.53]:46233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <npostavs@HIDDEN>) id 1hvZFA-0006nd-0h for 13400 <at> debbugs.gnu.org; Wed, 07 Aug 2019 23:37:36 -0400 Received: by mail-ot1-f53.google.com with SMTP id z23so4804627ote.13 for <13400 <at> debbugs.gnu.org>; Wed, 07 Aug 2019 20:37:35 -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=WsCml53Ya1UBqpg3NUC6Jax25nujGsg71MZ+pQTnn08=; b=qHfha80+SbMlPNm0zI2j+fZUIbbxQJjYeDQi1SOuJ5SxS6jMyp8WasqJ/CzTDfze+6 V5wPeasJmJ2gutt4juXU1kiCIGHViiJuhzkAKz6A0Y3Fsgdk72Ke5BX4nf0i9WC+Nqbp 6XVYkFA7DGbVJpYsK9Mt/rQisSB2FNwAf314O5pL6lXD+wDeLMFr4L8+1AKh/K7c/J/C Yv39I7mzA6UaYaql/zD6+zj0XNDww3+6oBKBAaa96+gkUYOVWUHiXT0wNWAkFAw0h6rL UCzXuyfAx2w2WjUuLqc4Sr5mpRLA3GsTmjwvxjFffSB0Me7KgEEHzs94UVJaz/T48uO2 4lqg== 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=WsCml53Ya1UBqpg3NUC6Jax25nujGsg71MZ+pQTnn08=; b=k25fUHw6+z8Y3blhXXOss9gjn2mzXA+UB/TkC8DSQwOM1b1Ze8rkdwLotabxabBM11 Hen1GfA6DQdlJdWbzjs3V6rt+rk+gbSiHmTnud3do0v9ZNNAzxWluzo2/wKJqWgcdsB4 Por+RUhAu6JrpoGKIYsMHJTtQZwlfQQk2/8ORZm/sR0NVSBHxRycA3vI7k2G/2GqVqhE XsdwTvNkm82uwvx63FfjFR11uZ+uxfiqCD+TIvQB8Z+8XgDLEporpcvFTdqhdN4fddyb fF64JX2jgxDj3gHtNx4UXSNmAjIRxJyvBQMVsd4lp5+1w+ZPu2ympmA0OuD2N2zVxC6p F8kw== X-Gm-Message-State: APjAAAXtlrgzTZkLe+C0vsAN7p12YvNhY+inRxNFIuv2yA5Pok/eX7L/ xFK3tRgtc2D7PnQoS+NRN4U= X-Google-Smtp-Source: APXvYqysEGiP1cRRn+eJKFE/kuIDqE1XW9yd+IgZZz7zzX2ozkXlImGz7TKrDo6KNKtMi6FLxSNp9w== X-Received: by 2002:a6b:6516:: with SMTP id z22mr12615792iob.7.1565235450350; Wed, 07 Aug 2019 20:37:30 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id c81sm144776419iof.28.2019.08.07.20.37.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Aug 2019 20:37:29 -0700 (PDT) From: Noam Postavsky <npostavs@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> <835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN> <jwvv9vbii0c.fsf-monnier+emacs@HIDDEN> Date: Wed, 07 Aug 2019 23:37:29 -0400 In-Reply-To: <jwvv9vbii0c.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Mon, 05 Aug 2019 14:31:39 -0400") Message-ID: <871rxws4xy.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13400 Cc: Eli Zaretskii <eliz@HIDDEN>, 13400 <at> debbugs.gnu.org, hendrik@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier <monnier@HIDDEN> writes: > I'm pretty sure that while there might be use-cases for recursive > invocation of filters, this is a very exceptional situation and the > average programmer will not expect it and would be stumped if/when > it happens. > > So the default should be to prevent it, with maybe some way to override > it to cater to the exceptional case where recursive invocation > is to be allowed. > > I think we could do that by setting a property on process object during > filter invocation to postpone further filter invocations, and then the > process filter could locally unset this property if it wants to allow > recursive invocations. Yeah, I suppose that would probably be better. Although then we have some potential weird edge cases like what happens when when changing the property during a recursive invocation.
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at 13400) by debbugs.gnu.org; 8 Aug 2019 01:16:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 07 21:16:00 2019
Received: from localhost ([127.0.0.1]:39718 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1hvX27-0001NS-Ps
for submit <at> debbugs.gnu.org; Wed, 07 Aug 2019 21:16:00 -0400
Received: from mail-ot1-f52.google.com ([209.85.210.52]:34308)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <npostavs@HIDDEN>) id 1hvX26-0001NG-KR
for 13400 <at> debbugs.gnu.org; Wed, 07 Aug 2019 21:15:59 -0400
Received: by mail-ot1-f52.google.com with SMTP id n5so112115229otk.1
for <13400 <at> 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)
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)
From: Noam Postavsky <npostavs@HIDDEN>
To: Hendrik Tews <hendrik@HIDDEN>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN>
<87wofr1bog.fsf@HIDDEN>
Date: Wed, 07 Aug 2019 21:15:49 -0400
In-Reply-To: <87wofr1bog.fsf@HIDDEN> (Hendrik Tews's message of
"Tue, 06 Aug 2019 00:37:19 +0200")
Message-ID: <874l2ssbi2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 13400
Cc: 13400 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Hendrik Tews <hendrik@HIDDEN> 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 <npostavs@HIDDEN>
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
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at 13400) by debbugs.gnu.org; 6 Aug 2019 07:40:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 06 03:40:56 2019
Received: from localhost ([127.0.0.1]:36398 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1huu5Y-00066I-I0
for submit <at> debbugs.gnu.org; Tue, 06 Aug 2019 03:40:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49910)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1huu5W-000665-Sr
for 13400 <at> debbugs.gnu.org; Tue, 06 Aug 2019 03:40:55 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1A65581183;
Tue, 6 Aug 2019 03:40:49 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5200380E08;
Tue, 6 Aug 2019 03:40:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1565077247;
bh=qjfsLroMY/zd44I5FcysWXCqwb7+hwJMSlDbFDL1oAg=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=nMnERCdjMOhl7IzQlhnEWmGty5pxGXTLeFJXe5WB6qysrWnCSsFXkORALVvPi7a6R
MaKM1C3sYKy01p+12QvffzS0qbYaI1LcWNS9XCaufhVTVaj0J4A6lhlrcVjY7SWDHW
oW6S2U1H/+I1rzQvmFUA+1Zz+AkZqZAkCHemTVm2HQQZlhKZRXTknOh0IvV6zvAxaW
mPuM+/g88RoytmKvQKYAXGOJBvle2i/2LOKEc/VjErSgtYwCxoElmu+zxuQPWTagCH
OjATWCoWe7+Kkg9le+QcJnlYWId+AZxnCxdpxlL2tQni4Cvunbptg+FRnzmBoM2AVv
WRBIDj9vuEMyQ==
Received: from alfajor (unknown [78.192.50.77])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9664C1202E7;
Tue, 6 Aug 2019 03:40:46 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Hendrik Tews <hendrik@HIDDEN>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Message-ID: <jwvwofqhhhy.fsf-monnier+emacs@HIDDEN>
References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN>
<87wofr1bog.fsf@HIDDEN>
Date: Tue, 06 Aug 2019 03:40:44 -0400
In-Reply-To: <87wofr1bog.fsf@HIDDEN> (Hendrik Tews's message of
"Tue, 06 Aug 2019 00:37:19 +0200")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 13400
Cc: 13400 <at> debbugs.gnu.org, Noam Postavsky <npostavs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> 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.
While I largely agree with your points, I'll mention that we *are*
plagued, because lots of functions may (in some cases) end up calling
a blocking operation. E.g. any call to a file function can block if the
file happens to be handled by Tramp, so any call to a function which
(transitively) calls a file function can itself block.
> 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...
I think preventing recursive filter invocations (by default) would be
much better than warning the programmer about that odd possibility.
Stefan
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 5 Aug 2019 22:37:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 05 18:37:31 2019 Received: from localhost ([127.0.0.1]:36007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hulbf-0000gR-03 for submit <at> debbugs.gnu.org; Mon, 05 Aug 2019 18:37:31 -0400 Received: from askra.de ([81.169.225.145]:49850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <hendrik@HIDDEN>) id 1hulbd-0000gJ-P3 for 13400 <at> debbugs.gnu.org; Mon, 05 Aug 2019 18:37:30 -0400 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 <hendrik@HIDDEN>) id 1hulba-0003yN-4F; Tue, 06 Aug 2019 00:37:26 +0200 Received: from localhost ([::1] helo=cert) by cert with esmtp (Exim 4.92) (envelope-from <hendrik@HIDDEN>) id 1hulbU-0008LB-F2; Tue, 06 Aug 2019 00:37:20 +0200 From: Hendrik Tews <hendrik@HIDDEN> To: Noam Postavsky <npostavs@HIDDEN> Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> Date: Tue, 06 Aug 2019 00:37:19 +0200 In-Reply-To: <87o91guoxl.fsf@HIDDEN> (Noam Postavsky's message of "Fri, 26 Jul 2019 23:38:46 -0400") Message-ID: <87wofr1bog.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13400 Cc: 13400 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Noam, thanks for addressing this quite old bug report. I do have some comments: Noam Postavsky <npostavs@HIDDEN> writes: > Hendrik Tews <hendrik@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at 13400) by debbugs.gnu.org; 5 Aug 2019 18:31:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 05 14:31:55 2019
Received: from localhost ([127.0.0.1]:35854 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1huhlz-00052c-3q
for submit <at> debbugs.gnu.org; Mon, 05 Aug 2019 14:31:55 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57681)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1huhlx-00052P-AF
for 13400 <at> debbugs.gnu.org; Mon, 05 Aug 2019 14:31:54 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7E34D81196;
Mon, 5 Aug 2019 14:31:47 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6A2C880D66;
Mon, 5 Aug 2019 14:31:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1565029902;
bh=fMLJAiHoKEy7tcJb3b8GPgkAXVYNAhgMf4Y7OZUu8y4=;
h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
b=R6DuqSLiSi8SvyLThhQ9K9goztVIJMgX0SJQhWyuMpbQSwAv4mUcn9GF6tmg5igXq
dBwu660uyQabUGbYnPMQKmZLNEruI0NS52mL4EQ0Wj1K0U/4JG8tyPvHfiEFfMICjX
DBWDoxwRKJK48gZPSgPPWwTvMnTls0QZCCyal+84LFKyBBJoMMB6lI6Qf5XYEw5SSx
GuBtL3+/2XhcJJsVQq9DSWTEUY2UJIH3u6wItoAw1WLWnUX8UhFokNYmZ+qGZBEtRT
FoUt4OkuQOHFzneczFVmkz0jLb3ooNDuTLlqPFjqXuLRjhZpMjqAukTS4BmYOGCilf
8gEqJfWHXXRFA==
Received: from alfajor (unknown [78.192.50.77])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B6DF0120CD0;
Mon, 5 Aug 2019 14:31:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Noam Postavsky <npostavs@HIDDEN>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Message-ID: <jwvv9vbii0c.fsf-monnier+emacs@HIDDEN>
References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN>
<835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN>
Date: Mon, 05 Aug 2019 14:31:39 -0400
In-Reply-To: <87pnllsspr.fsf@HIDDEN> (Noam Postavsky's message of "Sat, 03
Aug 2019 20:02:40 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
X-SPAM-LEVEL:
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 13400
Cc: Eli Zaretskii <eliz@HIDDEN>, 13400 <at> debbugs.gnu.org, hendrik@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
>>> > - "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?).
>>
>> I agree with Noam's decisions, and think that his patch is fine.
>>
>> Thanks.
>
> Any thoughts about make-buffered-filter? Leave it up to callers to
> write their own most situation-appropriate version of it? Add it as an
> example to the manual? Add it to Emacs?
I'm pretty sure that while there might be use-cases for recursive
invocation of filters, this is a very exceptional situation and the
average programmer will not expect it and would be stumped if/when
it happens.
So the default should be to prevent it, with maybe some way to override
it to cater to the exceptional case where recursive invocation
is to be allowed.
I think we could do that by setting a property on process object during
filter invocation to postpone further filter invocations, and then the
process filter could locally unset this property if it wants to allow
recursive invocations.
Stefan
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 4 Aug 2019 16:30:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 04 12:30:24 2019 Received: from localhost ([127.0.0.1]:34174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1huJOp-0007Xc-O9 for submit <at> debbugs.gnu.org; Sun, 04 Aug 2019 12:30:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1huJOo-0007XQ-32 for 13400 <at> debbugs.gnu.org; Sun, 04 Aug 2019 12:30:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1huJOh-0007wT-6b; Sun, 04 Aug 2019 12:30:16 -0400 Received: from [176.228.60.248] (port=4145 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1huJOg-0000py-Me; Sun, 04 Aug 2019 12:30:15 -0400 Date: Sun, 04 Aug 2019 19:29:59 +0300 Message-Id: <83wofsdhbs.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Noam Postavsky <npostavs@HIDDEN> In-reply-to: <87pnllsspr.fsf@HIDDEN> (message from Noam Postavsky on Sat, 03 Aug 2019 20:02:40 -0400) Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> <835znnnavb.fsf@HIDDEN> <87pnllsspr.fsf@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 13400 Cc: hendrik@HIDDEN, 13400 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Noam Postavsky <npostavs@HIDDEN> > Cc: hendrik@HIDDEN, 13400 <at> debbugs.gnu.org, monnier@HIDDEN > Date: Sat, 03 Aug 2019 20:02:40 -0400 > > Any thoughts about make-buffered-filter? Leave it up to callers to > write their own most situation-appropriate version of it? Add it as an > example to the manual? Add it to Emacs? I'd go with the example in the manual alternative.
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 4 Aug 2019 00:02:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 03 20:02:48 2019 Received: from localhost ([127.0.0.1]:60200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hu3z6-0005gq-4A for submit <at> debbugs.gnu.org; Sat, 03 Aug 2019 20:02:48 -0400 Received: from mail-io1-f50.google.com ([209.85.166.50]:39076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <npostavs@HIDDEN>) id 1hu3z4-0005gd-JP for 13400 <at> debbugs.gnu.org; Sat, 03 Aug 2019 20:02:46 -0400 Received: by mail-io1-f50.google.com with SMTP id f4so160209204ioh.6 for <13400 <at> debbugs.gnu.org>; Sat, 03 Aug 2019 17:02:46 -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=8Os7gmOD9yo+dZdbUDcNffPLLrQzKn29CKEA96wHk8g=; b=msva4qiTlY0ZJdWwInXuiG72Y/qz0CvdZ/CK6wv4d+t6z4/kvoDSiAHY0LF0Ro9PM0 cmoqQKUJNTm7VBNCwi2OTMBP4mBSiU82tSHmXS871cUXNgubhq9Bu76ZI7s659rgK+oU nhdv9FIjCQ9B7e/qohYjpfofjYyfJKi9KFhPgruWiPl5xWVtoyP5D5uLq6BQCZPY4AEC TfEPsw8GMJniz39XBoCsdVRrYMR6fm6xUTYkdm955W4o8oznRbr9GkcHCojcrN1sWlDi 1cP1AGarf04abzvOugfyBXffve3CuooLn+uf2+0yZu10v9rk6a5gDh91d3UvW1jSdcKg TunA== 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=8Os7gmOD9yo+dZdbUDcNffPLLrQzKn29CKEA96wHk8g=; b=AMDs/DoVWgxWxb0CHkD1U1+/10xULBf+e7CZ6xdLL5GR5Fax+a3F5PKjP1ezK6yBVm BsK9LKaydHqa7s/BoVl8fLTUsBGdZsjsqDfn5seoMvDYtodRY6DWRuyq/Qe3+NFn/xLe 9DL4KF6gOyToG5AcNu/idMzhrpB3YUU7FXYiEVdanXtBOSgh9QUZ16f3OpYmilSlbTLq O9FJfwyV4RddBzarmVluyk+5YnEGdk6ioIUhgQZq85ozq6qaxg2b3XvFgBWnghor0vV4 M/zDBFnj18vq+tgl9XM7TJYpZYu5nUP04ub2MRzPgxGekyzn3ObjYIsqpUlIT2S9GCH0 gxrw== X-Gm-Message-State: APjAAAX9AYFqfl4FpJP6PgdtriXxuSVEPAp0UWoWv9T2DAXrAFpX1we2 pF7JPK0jqMpQ+kWfL9s1Deg= X-Google-Smtp-Source: APXvYqzqNc162MWN+U0wkiER8LQH4r6hzxzHf7ATfOKokTvNkh2vOlfVRZfmJRj2F3KFPDZaoLolJg== X-Received: by 2002:a02:b713:: with SMTP id g19mr146099745jam.77.1564876961159; Sat, 03 Aug 2019 17:02:41 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id h19sm54122745iol.65.2019.08.03.17.02.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 03 Aug 2019 17:02:40 -0700 (PDT) From: Noam Postavsky <npostavs@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> <835znnnavb.fsf@HIDDEN> Date: Sat, 03 Aug 2019 20:02:40 -0400 In-Reply-To: <835znnnavb.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 27 Jul 2019 11:24:25 +0300") Message-ID: <87pnllsspr.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13400 Cc: hendrik@HIDDEN, 13400 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> > - "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?). > > I agree with Noam's decisions, and think that his patch is fine. > > Thanks. Any thoughts about make-buffered-filter? Leave it up to callers to write their own most situation-appropriate version of it? Add it as an example to the manual? Add it to Emacs?
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.Received: (at 13400) by debbugs.gnu.org; 27 Jul 2019 08:24:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 27 04:24:40 2019 Received: from localhost ([127.0.0.1]:43577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hrI0N-0003Je-Vt for submit <at> debbugs.gnu.org; Sat, 27 Jul 2019 04:24:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1hrI0M-0003JR-HU for 13400 <at> debbugs.gnu.org; Sat, 27 Jul 2019 04:24:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1hrI0G-0002n0-0B; Sat, 27 Jul 2019 04:24:32 -0400 Received: from [176.228.60.248] (port=4793 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1hrI0F-0005R8-BO; Sat, 27 Jul 2019 04:24:31 -0400 Date: Sat, 27 Jul 2019 11:24:25 +0300 Message-Id: <835znnnavb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Noam Postavsky <npostavs@HIDDEN> In-reply-to: <87o91guoxl.fsf@HIDDEN> (message from Noam Postavsky on Fri, 26 Jul 2019 23:38:46 -0400) Subject: Re: bug#13400: 23.4; overlapping process filter calls References: <87r4ltpctd.fsf@HIDDEN> <87o91guoxl.fsf@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 13400 Cc: hendrik@HIDDEN, 13400 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Noam Postavsky <npostavs@HIDDEN> > Date: Fri, 26 Jul 2019 23:38:46 -0400 > Cc: 13400 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> > > > - 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?). I agree with Noam's decisions, and think that his patch is fine. Thanks.
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at 13400) by debbugs.gnu.org; 27 Jul 2019 03:38:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 26 23:38:57 2019
Received: from localhost ([127.0.0.1]:43520 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1hrDXs-0002rf-OB
for submit <at> debbugs.gnu.org; Fri, 26 Jul 2019 23:38:57 -0400
Received: from mail-io1-f44.google.com ([209.85.166.44]:36751)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <npostavs@HIDDEN>) id 1hrDXq-0002rS-Fu
for 13400 <at> debbugs.gnu.org; Fri, 26 Jul 2019 23:38:55 -0400
Received: by mail-io1-f44.google.com with SMTP id o9so5252317iom.3
for <13400 <at> 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)
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)
From: Noam Postavsky <npostavs@HIDDEN>
To: Hendrik Tews <hendrik@HIDDEN>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
References: <87r4ltpctd.fsf@HIDDEN>
Date: Fri, 26 Jul 2019 23:38:46 -0400
In-Reply-To: <87r4ltpctd.fsf@HIDDEN> (Hendrik Tews's message of
"Thu, 10 Jan 2013 11:11:42 +0100")
Message-ID: <87o91guoxl.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 13400
Cc: 13400 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Hendrik Tews <hendrik@HIDDEN> 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 <npostavs@HIDDEN>
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))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 10 Jan 2013 10:12:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 10 05:12:09 2013
Received: from localhost ([127.0.0.1]:53354 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1TtF7J-0002Hs-4K
for submit <at> debbugs.gnu.org; Thu, 10 Jan 2013 05:12:09 -0500
Received: from eggs.gnu.org ([208.118.235.92]:60425)
by debbugs.gnu.org with esmtp (Exim 4.72)
(envelope-from <tews@HIDDEN>) id 1TtF7F-0002HM-VN
for submit <at> debbugs.gnu.org; Thu, 10 Jan 2013 05:12:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <tews@HIDDEN>) id 1TtF74-000662-Sn
for submit <at> debbugs.gnu.org; Thu, 10 Jan 2013 05:12:00 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:42960)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <tews@HIDDEN>) id 1TtF74-00065u-PR
for submit <at> debbugs.gnu.org; Thu, 10 Jan 2013 05:11:54 -0500
Received: from eggs.gnu.org ([208.118.235.92]:43538)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <tews@HIDDEN>) id 1TtF70-00079j-J4
for bug-gnu-emacs@HIDDEN; Thu, 10 Jan 2013 05:11:54 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <tews@HIDDEN>) id 1TtF6w-000652-7w
for bug-gnu-emacs@HIDDEN; Thu, 10 Jan 2013 05:11:50 -0500
Received: from srv4.sysproserver.de ([78.138.89.57]:41927)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <tews@HIDDEN>) id 1TtF6v-00063p-Ud
for bug-gnu-emacs@HIDDEN; Thu, 10 Jan 2013 05:11:46 -0500
Received: from wallace.tews.net (146-52-255-95-dynip.superkabel.de
[146.52.255.95])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by srv4.sysproserver.de (Postfix) with ESMTPSA id 95892C74003;
Thu, 10 Jan 2013 11:11:43 +0100 (CET)
Received: from tews by wallace.tews.net with local (Exim 4.80)
(envelope-from <tews@HIDDEN>)
id 1TtF6s-0001VR-HY; Thu, 10 Jan 2013 11:11:42 +0100
From: Hendrik Tews <hendrik@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 23.4; overlapping process filter calls
Date: Thu, 10 Jan 2013 11:11:42 +0100
Message-ID: <87r4ltpctd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -6.9 (------)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.9 (------)
Hi,
because Stefan Monnier asked for it
(http://lists.inf.ed.ac.uk/pipermail/proofgeneral-devel/2013/000296.html):
When a process filter does I/O (eg, process-send-string), it
might happen, that the same filter is called again for the same
process, while the first instance blocks. To reproduce, load the
code below and do M-x double-filter.
The problem is real with Coq Proof General and Prooftree. There,
Prooftree is driven from a process filter in Proof General. With
cold disk caches, it takes about 1 sec to start Prooftree (at
least on my laptops). Coq and Proof General easily fill the pipe
in that time, so that the process filter blocks inside
process-send-string. Meanwhile Coq continues to produce output
and the process filter is called again while the previous call
has not finished.
The more I think about it, I believe this is a feature.
However, the documentation is sometimes wrong and could be
clearer about this feature:
- Section "37.9 Receiving Output from Processes" does not list
process-send-string. How about other blocking I/O functions?
- Same in "37.9.2. Process Filter Functions"
- Same in "37.4 Creating an Asynchronous Process" ,
process-send-string is neither waiting for input not time
delay.
- "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.
- "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.
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.
===========================================================================
(defun double-filter ()
(interactive)
(setq df-process (start-process "tee" nil "/bin/cat"))
(set-process-filter df-process 'df-filter)
(set-process-sentinel df-process 'df-sentinel)
(set-process-query-on-exit-flag df-process nil)
(setq df-buf (get-buffer-create "xxxx"))
(process-send-string df-process "1\n"))
(setq df-filter-lock nil)
(setq df-error nil)
(defun df-filter (p str)
(unless df-error
(with-current-buffer df-buf
(insert (format "filter received %d bytes lock %s\n"
(length str) df-filter-lock)))
(when df-filter-lock
(setq df-error t)
(error "recursive filter"))
(setq df-filter-lock t)
(setq long (make-string 4096 65))
(process-send-string df-process long)
(process-send-string df-process long)
(process-send-string df-process long)
(process-send-string df-process long)
(process-send-string df-process long)
(process-send-string df-process long)
(process-send-string df-process long)
(process-send-string df-process long)
(setq df-filter-lock nil)))
(defun df-sentinel (p event)
(setq df-error t)
(with-current-buffer df-bug
(insert "process died\n")))
==============================================================================
In GNU Emacs 23.4.1 (i486-pc-linux-gnu, GTK+ Version 2.24.10)
of 2012-09-09 on murphy, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
configured using `configure '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.4/site-lisp:/usr/share/emacs/site-lisp' '--with-crt-dir=/usr/lib/i386-linux-gnu' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -DDEBIAN -O2' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
show-paren-mode: t
msb-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Hendrik Tews <hendrik@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#13400; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.