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, 09 Aug 2019 21:39:16 -0400 Message-ID: <878ss1re7v.fsf@gmail.com> References: <87r4ltpctd.fsf@wallace.tews.net> <87o91guoxl.fsf@gmail.com> <835znnnavb.fsf@gnu.org> <87pnllsspr.fsf@gmail.com> <871rxws4xy.fsf@gmail.com> <83a7cjbwyz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="246339"; 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, hendrik@askra.de To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 10 03:40:13 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 1hwGMc-0011xK-AM for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Aug 2019 03:40:10 +0200 Original-Received: from localhost ([::1]:34396 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwGMa-0002n5-MS for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2019 21:40:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47573) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwGMV-0002hv-K7 for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 21:40:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hwGMU-00056d-O8 for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 21:40:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34535) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hwGMU-00056V-Ko for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 21:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hwGMU-0003DF-9V for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 21:40: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, 10 Aug 2019 01:40:02 +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.156540116612302 (code B ref 13400); Sat, 10 Aug 2019 01:40:02 +0000 Original-Received: (at 13400) by debbugs.gnu.org; 10 Aug 2019 01:39:26 +0000 Original-Received: from localhost ([127.0.0.1]:43356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwGLu-0003CM-75 for submit@debbugs.gnu.org; Fri, 09 Aug 2019 21:39:26 -0400 Original-Received: from mail-ot1-f68.google.com ([209.85.210.68]:34133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwGLs-0003By-8Q for 13400@debbugs.gnu.org; Fri, 09 Aug 2019 21:39:24 -0400 Original-Received: by mail-ot1-f68.google.com with SMTP id n5so139785924otk.1 for <13400@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) Original-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) In-Reply-To: (Stefan Monnier's message of "Fri, 09 Aug 2019 17:36:34 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:164818 Archived-At: Stefan Monnier 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).