From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer Date: Thu, 10 Dec 2020 13:37:59 -0500 Message-ID: References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> <83360g6xlt.fsf@gnu.org> <87im9b2pds.fsf@gmail.com> <83k0tr5700.fsf@gnu.org> <87360d3dud.fsf@gmail.com> <83eejx4rd6.fsf@gnu.org> <87r1nx1vtd.fsf@gmail.com> <87mtyl1v6y.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16640"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 45117@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 19:39:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1knQqO-0004Fj-Na for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 19:39:12 +0100 Original-Received: from localhost ([::1]:40984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knQqN-0005IW-Qy for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 13:39:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knQqF-0005Gg-JU for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:39:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55949) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knQqD-0003M3-Ti for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:39:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knQqD-0003oc-QJ for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:39:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Dec 2020 18:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45117 X-GNU-PR-Package: emacs Original-Received: via spool by 45117-submit@debbugs.gnu.org id=B45117.160762549814609 (code B ref 45117); Thu, 10 Dec 2020 18:39:01 +0000 Original-Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 18:38:18 +0000 Original-Received: from localhost ([127.0.0.1]:39262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQpV-0003nZ-Pg for submit@debbugs.gnu.org; Thu, 10 Dec 2020 13:38:18 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQpR-0003nK-Bh for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 13:38:17 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 95FD54409DA; Thu, 10 Dec 2020 13:38:07 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D255F4409D5; Thu, 10 Dec 2020 13:38:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607625485; bh=tKWZh60tD1iwJRG11NaDS2CmVqQQ28ys/NU01642HmQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OVRnnlbYEVf6SEoT6hrB40UlKffdcS8bodc4ZyYLJgGTr07DGClst8cmMlNMkHgqA JbvYfaRBuGcJKObaEiZhBPu9P/xl6fVb1VZNxlFymqSNmlw7okvLiktDQSlQFyDqQk d+gDttMuJdNG+wkIWKBm6PYYG/WbQ0L86R5eyRfRpPc7ue5rnkXIJDidWWkxpgWX23 Jw65CiOm/XIu92MS3WVKFIe23+BhptU6Q0dKzc/+Doqo98ovpLv1kYo7u6HKxcVK72 OWPriPCZgL5m4H7ctFjp4wU6S91KiCmHkPFlT7//OmoFgK4y0ppK67deAz3dsjAflK 1yBQ8DmzEWvPA== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 99E591203CA; Thu, 10 Dec 2020 13:38:05 -0500 (EST) In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Thu, 10 Dec 2020 18:05:54 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195681 Archived-At: > I'm not sure. Every such async system eventually boils down > to a point that sends something to the wire (step A) and a process > filter (step C) that runs later on and finds some suitable "continuation", > (a callback). [ I'm not completely sure I understand your scenario above, so we may be miscommunicating. ] Right. And `while-no-input` should only wrap the execution of A, so if A doesn't complete, then presumably none of C nor B will want to be executed, which seems OK. IOW the only real problem is if A is interrupted before completing but after starting to send something on the wire. In that case, the subprocess may left hanging waiting for more data. This can be handled in two different ways: by inhibiting quit around the "sends" (I generally recommend against inhibiting quit, so it's not the option I favor) or by using an unwind-protect that "kills" the subprocess or closes the pipe in case we're exiting before having sent all the data (that's a good idea to do also in case a bug signals an error). > Actually, thinking more about it. I don't think it's sound to have a > while-no-input at all under library control. A programmer using > that library should be given a predictable evaluation model. At > any rate, this is a regression from 26.3, where things didn't work > like this. The exact same problem affects all normal Elisp code when the user hits C-g, so I think the better path forward is to make sure it's "easy and natural" to write code which reacts correctly when it's aborted at some arbitrary time. We usually get that via `unwind-protect`, but if it's not enough we should develop better solutions rather than shy away from `quit`. But I had the impression that the original problem under discussion was not just due to the difficulty of writing code that handles "random aborts", but rather due to the fact that `while-no-input` sometimes caused undesired random aborts even when the user didn't hit any key. This would be a bug in `while-no-input` which we should investigate a fix (it's likely due to some "innocuous" event being received which `while-no-input` mistakes for user-input; could be an event linked to some kind of notification service like dbus, file-notifications, ...). Stefan