From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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 18:50:33 +0000 Message-ID: <87h7ot1ona.fsf@gmail.com> 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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32655"; 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: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 19:51:29 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 1knR2G-0008Nt-27 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 19:51:28 +0100 Original-Received: from localhost ([::1]:51508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knR2E-0002TS-W6 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 13:51:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knR1q-0002T9-0p for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:51:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55969) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knR1p-0007KG-Pc for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:51:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knR1p-00047D-NJ for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 13:51:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Dec 2020 18:51: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.160762624715799 (code B ref 45117); Thu, 10 Dec 2020 18:51:01 +0000 Original-Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 18:50:47 +0000 Original-Received: from localhost ([127.0.0.1]:39282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knR1a-00046l-N7 for submit@debbugs.gnu.org; Thu, 10 Dec 2020 13:50:47 -0500 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:37310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knR1X-00046W-WC for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 13:50:46 -0500 Original-Received: by mail-wr1-f46.google.com with SMTP id i9so6572001wrc.4 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 10:50:43 -0800 (PST) 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:content-transfer-encoding; bh=WdBYhVF1rjGUFrT4geLHCwxQDcVFJjAEv4XvIp84Xag=; b=ZLh2MF78KQgn6gGFFQYeauaoZGjvtijilsZ1HZRx7j2375Ru2iQGUqSxQKNc6EiZSi NeC/VrjRM/jSghSped0PAIhu/Ar6qGYUFCEWJg657uRv+MShJomRaPlhfHpBiljLCBLU bi+DK6ofN5+bF3prAQCFYAZNNSKu0nhf+keqIFJspEzuEngW1IQkBn2y9izknXfYdXWj JSxXy9g+VyS3vXyeHEDU7BtEnTWEThET22oezZtjErwAnHX+435yQNPsbHqtyqcfFmuF PbMut3vEW0ma0OeENteXOhddqhBvxJ+1Daf6duEoiMNPUJIpxd9RHLmE71j7T7yvzpe8 qqyQ== 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:content-transfer-encoding; bh=WdBYhVF1rjGUFrT4geLHCwxQDcVFJjAEv4XvIp84Xag=; b=lR3pa7yMXJCQ2zYxXR3DpqupxZg/nntBNNBd0gshTpCcOYq8OOnv6fcZawLSCqVesN uCvAolo3rey1olBhvWn9xEh9/CMcxytcc+OLl/8kSRK85bri9GWc3I5Ri8OjB6nJVMrA 6cnt/RfsEh6wGxHIirVSCEQOxK6V60JBJgBvux90+EI78PFMKr7kI2co2QncIxPXMpto hZTemARU7jdsGGRr8RLgElMBdpfYAYsVpm/dfViQnWFLhPwsP0svBB9ey3j41vwuICU1 L3fzKwBOkCoOJK/k3eFogJFmI6M4g9UVZQxwIKVo6Z5KmyHQ8TIzyPmtswM5QOKzWo/b I/Zw== X-Gm-Message-State: AOAM532IaJVk5RYP1R2YqdbYcNfkHinWlY72hmUL8pE+gqVIgf8q5tyz X8p7M4uQMmGHkpWKekA5KN7O7ad+M30= X-Google-Smtp-Source: ABdhPJwV+bsiU5vIU6QFOI3nO0ELmxpqyr0c7K7LvXq13EGTPMxebE3vOgt0uxwUlQQrp7i9YIIuiA== X-Received: by 2002:adf:fc49:: with SMTP id e9mr9717145wrs.31.1607626237665; Thu, 10 Dec 2020 10:50:37 -0800 (PST) Original-Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id y68sm12122744wmc.0.2020.12.10.10.50.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 10:50:36 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Thu, 10 Dec 2020 13:37:59 -0500") 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:195685 Archived-At: Stefan Monnier writes: >> 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. We are miscommunicating. In these programs, B needs to be atomic with A. When you send things into an external process, only the most naive of external communication protocol replies immediately and synchronously to the thing you just sent. For those super simple things, like "cat" and "grep", your model works. But a complex multi-threaded program being talked to via the network, will process requests it is fed through the wire in varying rates and rythms. So you need system in the Elisp side that decodes what async request the process is responding to. See jsonrpc.el's jsonrpc-connection-receive, for instance. > 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). Again, this killing of the subprocess assumes the trivial case of a unix utility. >> 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`. I get what you're saying, but there's a presumably reason we bind inhibit-quit to t in timers (Eli?), and it's that that code isn't triggered by a direct action of he user. Indeed in idle timers, it's triggered by the _inaction_ of the user. So it makes no sense to also use that allow quitting model there, unless the programmer of the timer function expects to do something very lengthy, whereup he should consciously turn it off, either via while-no-input or some other mechanism. Doing that for her in the library is violating the premise of timer functions as one knows them. > 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, ...). Yes, there is that too. While-no-input has all those Heisenbergian effects to add to it. But this was no heisenberg, I think. I was pressing C-n the whole time, so that's "input". Jo=C3=A3o