From unknown Sat Jun 21 10:22:02 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#45117 <45117@debbugs.gnu.org> To: bug#45117 <45117@debbugs.gnu.org> Subject: Status: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer Reply-To: bug#45117 <45117@debbugs.gnu.org> Date: Sat, 21 Jun 2025 17:22:02 +0000 retitle 45117 28.0.50; process-send-string mysteriously exiting non-locally= when called from timer reassign 45117 emacs submitter 45117 Jo=C3=A3o T=C3=A1vora severity 45117 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 06:44:59 2020 Received: (at submit) by debbugs.gnu.org; 8 Dec 2020 11:44:59 +0000 Received: from localhost ([127.0.0.1]:56727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmbQQ-0005Rl-PQ for submit@debbugs.gnu.org; Tue, 08 Dec 2020 06:44:59 -0500 Received: from lists.gnu.org ([209.51.188.17]:47038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmbQN-0005RZ-GX for submit@debbugs.gnu.org; Tue, 08 Dec 2020 06:44:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47076) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmbQL-0006rn-JA for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 06:44:55 -0500 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:55298) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kmbQF-0000Q4-GI; Tue, 08 Dec 2020 06:44:53 -0500 Received: by mail-wm1-x32a.google.com with SMTP id x22so1828220wmc.5; Tue, 08 Dec 2020 03:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Sb9N9notJM/OQfF8tvtTXUQxyY0CTWZEsdpDbGTT0Ps=; b=hJRfhLErWqmFCn7HzMFfFPPzusjQKg/8m3scO+aJC9fYsYqBoFGbLr0kBctiFIbz58 DKy/aaYcbrm9Wh1TDtNEliWBTBEWMB13EIaO1aPLVzs5euNtVNH1RliHaIx2eHX17Y6y MNdaneGwkDGdrojZiUNdvKayCFC3vI6WzGmj3ohG9ReJA33TGIJgNDx1DbzXNh67lXp4 qHekGilBT0mwAtgeZKt9NitXdlQIONxJF9EE2cyfl/4OOaSw57Jg/MpaGVvXmB7RGWxT O7FIJkThTQpsL5QcOua9Le/8s1MaktZ/DvnHC0xzo2BVHWEm0JWx3peJvFT9NH9HzvMq qo8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Sb9N9notJM/OQfF8tvtTXUQxyY0CTWZEsdpDbGTT0Ps=; b=HXzX8/XiHOhdamSnpUMvG1Odyqd24mWF48bvc1xif8tjnd7sI+4eIWS6kS07tPNCLR FLg+r7NcRfyD9o0+fRnYnlFNLsvK0Hn594/rZfelkf5Z/d16qA8deuQrT0cr+8J7pIG1 iLD59/O5IoBSpw6WzE4Co8UlOha4DEHJM0U1OQp0dOS5ZoGKWhu2gthrt6pdeqdNQLdi xm4SyJvAf6Rk06bSSieWdt+7YTKjEuo5pOkYkspKtMh8lJgs8QFku6zinWE/g3nVfTc5 kwtjNNysNP3XA4deXbde2Ct58FV6fpKFv1LlqDz0eRn1BL4EbovLIrPhrc+kFI3aUT34 TwWQ== X-Gm-Message-State: AOAM530cyZ3AIGJHSfi/sYbBphO0Jt8Tco+lSF0I6zfRgvC+99jxAJAx zhS0nU3hOtcJ3LPnlnq2M5uIs4HUYhI= X-Google-Smtp-Source: ABdhPJzzw8fyeagwNihxbx9p7lb0Id5F4gCYeIvegscE4e0dxQvCZNZNZy4f0Zv1TcD7HNgix6yLFA== X-Received: by 2002:a1c:a9c4:: with SMTP id s187mr3528529wme.116.1607427881850; Tue, 08 Dec 2020 03:44:41 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id j7sm3088010wmb.40.2020.12.08.03.44.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 03:44:41 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: bug-gnu-emacs@gnu.org, eliz@gnu.org Subject: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer Date: Tue, 08 Dec 2020 11:44:39 +0000 Message-ID: <87h7ow4j4o.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x32a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi Maintainers, Eli When using SLY Common Lisp IDE package for Emacs, a user has recently reported a strange intermittent error in SLY's asynchronous ElDoc function. That function produces documenttion by querying a network process, a common technique in many such IDEs. The user found that when reducing eldoc-idle-delay to 0.1 he could trigger the problem more often. The original report lives at https://github.com/joaotavora/sly/issues/385. It was triggered with Emacs 27.1, but I have also reproduced it with a recent master build. After analysing the problem, I came to the conclusion that given certain mysterious conditions, process-send-string, which is called from SLY's `eldoc-documentation-function` will abruptly return non-locally even though no error or quit seems to have been signalled. For now, reproducing this means installing SLY, which is easily done with a git clone of its source at github.com/joaotavora/sly.git. One also needs a `lisp` executable pointing to something like SBCL (South Bank Common Lisp). Then emacs -Q -L . -l sly-autoloads -f sly should bring up Emacs with SLY and nothing else. To trigger the error it's easier to M-: (setq eldoc-idle-delay 0.05) C-x C-f ~/path/to/sly/slynk/slynk.lisp ;; or some other lisp file Now, the user should navigate around, triggering ElDoc and seeing the documentation in the echo area, until one gets an "unexpected reply" error in the minibufer. Interestingly, this unexpected reply comes from the fact that the network process where process-send-string is writing to has already processed the request (presumably fully), and has answered. Thus the process's filter function has been run with that output. Unfortunately, because process-send-string exited prematurely and non-locally (under line 2 in the sly.el snippet below), the so-called continuation lambda hasn't been registered (line 3). Thus when the filter function runs (code not shown) it will fail to find the continuation and report an unexpected reply. 1 (let ((id (cl-incf (sly-continuation-counter)))) 2 (sly-send `(:emacs-rex ,form ,package ,thread ,id ,@extra-options)) 3 (push (cons id continuation) (sly-rex-continuations)) 4 (sly--refresh-mode-line)) Reading process-send-string's docstring I see no mention of this possibility, only the fact that output can be accepted between bunches of strings. While the latter could happen, I'm pretty sure that the Lisp network process wouldn't have enough information to work with, prematurely, so I don't think that's the reason for the unexpected reply. Moreover, reading the C source for process.c I do see some worries with timers in code comments. However, I cannot correlate those worries with this use case. I'll be soon patching this in SLY with an unwind-protect that only adds the continuation if process-send-string has exited locally. That should hide this hard-to-trigger problem, but the underlying problem remains. Thanks for your attention, Jo=C3=A3o PS: Recently, I've also seen similar "silent" non-local-exits with accept-process-output when called from filter functions, but I will report these separately once I have better reproduction recipes. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 10:40:05 2020 Received: (at submit) by debbugs.gnu.org; 8 Dec 2020 15:40:06 +0000 Received: from localhost ([127.0.0.1]:59252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmf5x-0004wQ-JR for submit@debbugs.gnu.org; Tue, 08 Dec 2020 10:40:05 -0500 Received: from lists.gnu.org ([209.51.188.17]:38014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmf5v-0004wH-JF for submit@debbugs.gnu.org; Tue, 08 Dec 2020 10:40:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmf5v-0006tm-9E for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 10:40:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52610) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmf5v-0008TR-0p; Tue, 08 Dec 2020 10:40:03 -0500 Received: from [176.228.60.248] (port=2092 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kmf5t-0002jo-CB; Tue, 08 Dec 2020 10:40:01 -0500 Date: Tue, 08 Dec 2020 17:39:54 +0200 Message-Id: <83mtyo71dh.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87h7ow4j4o.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Tue, 08 Dec 2020 11:44:39 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer References: <87h7ow4j4o.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Tue, 08 Dec 2020 11:44:39 +0000 > > When using SLY Common Lisp IDE package for Emacs, a user has recently > reported a strange intermittent error in SLY's asynchronous ElDoc > function. That function produces documenttion by querying a network > process, a common technique in many such IDEs. The user found that when > reducing eldoc-idle-delay to 0.1 he could trigger the problem more > often. > > The original report lives at > https://github.com/joaotavora/sly/issues/385. > > It was triggered with Emacs 27.1, but I have also reproduced it with a > recent master build. > > After analysing the problem, I came to the conclusion that given certain > mysterious conditions, process-send-string, which is called from SLY's > `eldoc-documentation-function` will abruptly return non-locally even > though no error or quit seems to have been signalled. Can you elaborate on the evidence you found of this non-local exit? And does "no error or quit" mean there's no trace of anything abnormal in the *Messages* buffer? One possible reason for non-local exit, besides signaling an error, is stack overflow, although your description doesn't seem to indicate that this is probable. One other piece of information that could be relevant is that when Emacs calls the timer function, it sets inhibit-quit non-nil. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 10:56:59 2020 Received: (at submit) by debbugs.gnu.org; 8 Dec 2020 15:57:00 +0000 Received: from localhost ([127.0.0.1]:59282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmfMJ-0005NI-5R for submit@debbugs.gnu.org; Tue, 08 Dec 2020 10:56:59 -0500 Received: from lists.gnu.org ([209.51.188.17]:53556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmfMH-0005N9-2o for submit@debbugs.gnu.org; Tue, 08 Dec 2020 10:56:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmfMG-0005kq-QJ for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 10:56:56 -0500 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:50708) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kmfMF-00062c-2q; Tue, 08 Dec 2020 10:56:56 -0500 Received: by mail-wm1-x330.google.com with SMTP id c198so2467372wmd.0; Tue, 08 Dec 2020 07:56:53 -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=O1RYlGCSQ3Dv8410JSm1slTANB/3laWOugi1EZlaWOk=; b=YJrkd6JzxTj5DmlXdBmFrgz0TAj/5R1uhh7WODQor7L97MNS7n5tzRzRrGwWqKE4vm /xjmcWOGkyQh7nILURB9ByShJwQQ4/54x4WZPOuNS0peSmbZsx/Rcip5rHcWbCU6Hm52 rw1urj/4TmvYjdhw4ihWfI11OiI/qRIMSD9h8ZKGVt9krFj6FiA3zugFMnpf/VcBcx7r o4xa7fw77YiSXBTe5ZrG49V/OREmxK8eTx1l3LZecQnuwdalKCcqFr47FEVJU1EnfnEP 11W/zGBM3gvhx1GgVn/w9NVlIC7nds8P/a104DIqM+0sL4pR1NBhvHqrJbWSnsGDokXP KQvA== 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=O1RYlGCSQ3Dv8410JSm1slTANB/3laWOugi1EZlaWOk=; b=Z77L3JSnTY5oWyJQr5sE7fKwhtsDp0BCfTwNOYUcXjls+Qdy8yrWdjQmkzSJlLjWOQ Qmt1rWSCpM+l1M1oh5J3v1uwVJ//ji3o7xV8q7E8+QCd+jaGhVifoMz1HJ9PJYoV/BUe 3awqr8Ym0XRb1IwLe//rzrw+5/d/3E4gf7maWLDHreP10tfLZPyPSR9OMLkNbsIfC/tz NG6SCaVawoLQJ6PmnjH2ASYm5qzRiJXzP0Z2n7PnE+UHTU6cmF0I+vHFo2V9wgo8E5mF edM/Sd15jgyNxbLHwdMH7jn1SOsrrLrEpe8OMMQT9Htgt+b3eXB8DupNOBlK/WTjvz09 DfOg== X-Gm-Message-State: AOAM5338xBcV91J7ZmCBl65SarGpxp/gdZvDPh++SvLdMf131tgt9v8P HhuapRlTchbmMHdhdlBXJ0+IFASO4wc= X-Google-Smtp-Source: ABdhPJzep1MaD4KwPfRgt5R+CuqKidT63GxZl2Hb6BKRfKzwHRakoQgBoIHChw0zha8Qq2lSo8Hulg== X-Received: by 2002:a7b:c773:: with SMTP id x19mr4315921wmk.127.1607443011741; Tue, 08 Dec 2020 07:56:51 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id i8sm4151275wma.32.2020.12.08.07.56.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 07:56:51 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> Date: Tue, 08 Dec 2020 15:56:49 +0000 In-Reply-To: <83mtyo71dh.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Dec 2020 17:39:54 +0200") Message-ID: <877dps47ge.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x330.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Date: Tue, 08 Dec 2020 11:44:39 +0000 >>=20 >> When using SLY Common Lisp IDE package for Emacs, a user has recently >> reported a strange intermittent error in SLY's asynchronous ElDoc >> function. That function produces documenttion by querying a network >> process, a common technique in many such IDEs. The user found that when >> reducing eldoc-idle-delay to 0.1 he could trigger the problem more >> often. >>=20 >> The original report lives at >> https://github.com/joaotavora/sly/issues/385. >>=20 >> It was triggered with Emacs 27.1, but I have also reproduced it with a >> recent master build. >>=20 >> After analysing the problem, I came to the conclusion that given certain >> mysterious conditions, process-send-string, which is called from SLY's >> `eldoc-documentation-function` will abruptly return non-locally even >> though no error or quit seems to have been signalled. > > Can you elaborate on the evidence you found of this non-local exit? It was evidenced by M-x trace-function process-send-string RET and also by substituting the snippet I posted earlier with: (unwind-protect (progn (sly-send `(:emacs-rex ,form ,package ,thread ,id ,@extra-options)) (setq send-success t)) (if send-success (push (cons id continuation) (sly-rex-continuations)) (sly-message "[issue#385] likely `process-send-string' exited non-locally from t= imer.") (sly-log-event `(:issue-385-sly-send-fishiness :id ,id :form ,form ) sly-dispatching-connection))) Once in a while, the else branch of the if triggered. Anyway, here's an observation: 1 -> (process-send-string # "00044d(:emacs-rex (slynk:autodoc (quote (\"defpackage\" \":slynk\" (\":use\" \":cl\" \":slynk-backend\" \":slynk-match\" \":slynk-rpc\") (\":export\" \"#:startup-multiprocessing\" \"#:start-server\" \"#:create-server\" \"#:stop-server\" \"#:restart-server\" \"#:ed-in-emacs\" \"#:inspect-in-emacs\" \"#:print-indentation-lossage\" \"#:invoke-sly-debugger\" \"#:slynk-debugger-hook\" \"#:emacs-inspect\" \"#:authenticate-client\" \"#:*loopback-interface*\" \"#:*buffer-readtable*\" \"#:process-requests\") (\":export\" \"#:*communication-style*\" \"#:*dont-close*\" \"#:*fasl-pathname-function*\" \"#:*log-events*\" \"#:*log-output*\" \"#:*configure-emacs-indentation*\" \"#:*readtable-alist*\" \"#:*global-debugger*\" \"#:*sly-db-quit-restart*\" \"#:*backtrace-printer-bindings*\" \"#:*default-worker-thread-bindings*\" \"#:*macroexpand-printer-bindings*\" \"#:*slynk-pprint-bindings*\" \"#:*string-elision-length*\" \"#:*inspector-verbose*\" \"#:*require-module*\" \"#:*eval-for-emacs-wrappers*\" \"#:*debugger-extra-options*\" \"#:*globally-redirect-io*\" \"#:*use-dedicated-output-stream*\" \"#:*dedicated-output-stream-port*\" slynk::%cursor-marker%))) :print-right-margin 80) \":slynk\" t 100) ") 1 <- process-send-string: !non-local\ exit! This was was pretty long, but it can be slower. Also it was after 100 successful similar calls. > And does "no error or quit" mean there's no trace of anything abnormal > in the *Messages* buffer? Yes, exactly. > One possible reason for non-local exit, besides signaling an error, is > stack overflow, although your description doesn't seem to indicate > that this is probable. Indeed. > One other piece of information that could be relevant is that when > Emacs calls the timer function, it sets inhibit-quit non-nil. Right, and I added a formatting of quit-flag to the message call I showed earlier and it came out nil. [sly] [issue#385] likely `process-send-string' exited non-locally from t= imer, also quit-flag =3D nil. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 12:01:31 2020 Received: (at submit) by debbugs.gnu.org; 8 Dec 2020 17:01:32 +0000 Received: from localhost ([127.0.0.1]:59418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmgMl-0006M3-BJ for submit@debbugs.gnu.org; Tue, 08 Dec 2020 12:01:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:49434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmgMj-0006K8-Ej for submit@debbugs.gnu.org; Tue, 08 Dec 2020 12:01:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmgMh-0001fO-Hx for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 12:01:29 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54352) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmgMh-000468-9g; Tue, 08 Dec 2020 12:01:27 -0500 Received: from [176.228.60.248] (port=3104 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kmgMe-0004t9-RX; Tue, 08 Dec 2020 12:01:26 -0500 Date: Tue, 08 Dec 2020 19:01:18 +0200 Message-Id: <83360g6xlt.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <877dps47ge.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Tue, 08 Dec 2020 15:56:49 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: bug-gnu-emacs@gnu.org > Date: Tue, 08 Dec 2020 15:56:49 +0000 > > > Can you elaborate on the evidence you found of this non-local exit? > > It was evidenced by M-x trace-function process-send-string RET and also > by substituting the snippet I posted earlier with: > > (unwind-protect > (progn > (sly-send `(:emacs-rex ,form ,package ,thread ,id ,@extra-options)) > (setq send-success t)) > (if send-success > (push (cons id continuation) (sly-rex-continuations)) > (sly-message > "[issue#385] likely `process-send-string' exited non-locally from timer.") > (sly-log-event `(:issue-385-sly-send-fishiness :id ,id > :form > ,form ) > sly-dispatching-connection))) > > Once in a while, the else branch of the if triggered. > > Anyway, here's an observation: > > 1 -> (process-send-string # "00044d(:emacs-rex > (slynk:autodoc (quote (\"defpackage\" \":slynk\" (\":use\" \":cl\" > \":slynk-backend\" \":slynk-match\" \":slynk-rpc\") (\":export\" > \"#:startup-multiprocessing\" \"#:start-server\" \"#:create-server\" > \"#:stop-server\" \"#:restart-server\" \"#:ed-in-emacs\" > \"#:inspect-in-emacs\" \"#:print-indentation-lossage\" > \"#:invoke-sly-debugger\" \"#:slynk-debugger-hook\" \"#:emacs-inspect\" > \"#:authenticate-client\" \"#:*loopback-interface*\" > \"#:*buffer-readtable*\" \"#:process-requests\") (\":export\" > \"#:*communication-style*\" \"#:*dont-close*\" > \"#:*fasl-pathname-function*\" \"#:*log-events*\" \"#:*log-output*\" > \"#:*configure-emacs-indentation*\" \"#:*readtable-alist*\" > \"#:*global-debugger*\" \"#:*sly-db-quit-restart*\" > \"#:*backtrace-printer-bindings*\" > \"#:*default-worker-thread-bindings*\" > \"#:*macroexpand-printer-bindings*\" \"#:*slynk-pprint-bindings*\" > \"#:*string-elision-length*\" \"#:*inspector-verbose*\" > \"#:*require-module*\" \"#:*eval-for-emacs-wrappers*\" > \"#:*debugger-extra-options*\" \"#:*globally-redirect-io*\" > \"#:*use-dedicated-output-stream*\" \"#:*dedicated-output-stream-port*\" > slynk::%cursor-marker%))) :print-right-margin 80) \":slynk\" t 100) ") 1 > <- process-send-string: !non-local\ exit! Then my suggestion is to run this under GDB with a breakpoint on the few places we call sys_longjmp, and when it breaks, show the C and Lisp backtrace from there. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 08 12:05:38 2020 Received: (at submit) by debbugs.gnu.org; 8 Dec 2020 17:05:38 +0000 Received: from localhost ([127.0.0.1]:59438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmgQk-0007Hb-24 for submit@debbugs.gnu.org; Tue, 08 Dec 2020 12:05:38 -0500 Received: from lists.gnu.org ([209.51.188.17]:57734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmgQf-0007HQ-2x for submit@debbugs.gnu.org; Tue, 08 Dec 2020 12:05:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmgQe-0005Tu-T1 for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2020 12:05:32 -0500 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]:40142) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kmgQd-0005eS-Br; Tue, 08 Dec 2020 12:05:32 -0500 Received: by mail-il1-x129.google.com with SMTP id g1so16114768ilk.7; Tue, 08 Dec 2020 09:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KGx7sNOpjv6badRJlxcEMHJwkOhQmnUAUG8SYEV/dIs=; b=LifD8E/+gqHUKkgqNbUQb8SRHwrXmgKruUlQOUy4JRdRLWuY7FkQrAlBJ6zeFSnubv XHAH2qebQydtW0jXcsro2n/48irg+QuSmEKCij1SI7Wgf6a5M+nlU7wBaJh4u5dfX4ii ukXzp7RduPpBvFcaZ4TwdIFKS/tAB5IZEIthF4yjBB9QUqAjXdJy0kHkJ7WTz0N53hUF ico4GBVObIl1SzQ2zSldIfs0FCqoTy4CrBcUO8XS5JJUQezd/gfu6F92MnaM8n0cDGnu 83iEwsQFfwtGpsSuLMtA8RjatC6ZnNTKJ5og8fILkgYtnsr5oUMMGHyVx8Hf+ab43VBp hadw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KGx7sNOpjv6badRJlxcEMHJwkOhQmnUAUG8SYEV/dIs=; b=sZEtcuJEN8I5vmh7+sgLlObXIWBMXWpDlwfss4TdRfe3XQBx6gTz3DCPpxp/O4mhB+ Rsp7RnfP5VXOUkzACEc2DbxD2Y3D34DMED0Q/TFiSNER52D6GHFRu7DZ/C5/BxQ2EmCC ljCduEhWL4aUlkvGaX9WmW/i7Zaud0SybLVMi2cgfQNbUZy4uMbNOXvJFXTAqIDEbATI z7Ah9TCL6n+MAXOMla6BPgWJUT4wQCJiSQc6+xWMoKCI5ybit0GSeAU/VIDOyn67BHLM /LnzL/FtpUj5m5sbChVNl2JNe7XVt5M72EE1OLurVgUiKyUrk/FkMHUhidiOAWSGZQit pC6g== X-Gm-Message-State: AOAM531MQ+cJe30XZokEnsTJ9Es9etsijSwbQIkJOZmu6G7/AL3MDrPf H+L50sS5vd7psxOnDctEzrj1Zzo3BSlGkjnjHKYPrn+E X-Google-Smtp-Source: ABdhPJysMvuQ3BW3ofVMKmnHtBeCGKzLgxqdhEs8q6alKFSrcWnOlHDGWpVZnUAxqgYnO0cflhVEyBo+pprffJjMqFI= X-Received: by 2002:a05:6e02:14ce:: with SMTP id o14mr28201726ilk.9.1607447128450; Tue, 08 Dec 2020 09:05:28 -0800 (PST) MIME-Version: 1.0 References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> <83360g6xlt.fsf@gnu.org> In-Reply-To: <83360g6xlt.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 8 Dec 2020 17:05:16 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::129; envelope-from=joaotavora@gmail.com; helo=mail-il1-x129.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On Tue, Dec 8, 2020 at 5:01 PM Eli Zaretskii wrote: > Then my suggestion is to run this under GDB with a breakpoint on the > few places we call sys_longjmp, and when it breaks, show the C and > Lisp backtrace from there. Right. I suspected you'd say that :-) I wish I had this more oiled up, bu= t it should be faster to set up than last time. And likely I can catch that other accept-process-output thing in the act, too. Thanks, Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 06:24:59 2020 Received: (at 45117) by debbugs.gnu.org; 9 Dec 2020 11:24:59 +0000 Received: from localhost ([127.0.0.1]:32907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmxad-0005vF-I6 for submit@debbugs.gnu.org; Wed, 09 Dec 2020 06:24:59 -0500 Received: from mail-wm1-f45.google.com ([209.85.128.45]:51050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmxab-0005v2-9X for 45117@debbugs.gnu.org; Wed, 09 Dec 2020 06:24:58 -0500 Received: by mail-wm1-f45.google.com with SMTP id c198so1140381wmd.0 for <45117@debbugs.gnu.org>; Wed, 09 Dec 2020 03:24:57 -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=ESoRl4SVY0pOE6ZKle505GcXld13ZmPGzLBjTxBd8EY=; b=Zz3J/kfOH/bPSjI3FJw6Qmmn5FngvSewn1CducLXTM8m5tBaY8o8l3AsoHoUHGvyYQ LI4gvL7JP6kURxw2ju8Zw2MXK7Cxbuzu9T7XHU7PB0VYr9Ojx6SHESdAjdjJ9L+MolxS g0oBrZ3Vz+UhPrc32KOG16Um9jY6grX7RoV4FC3swl0kvOYWrA6R+1DBzM+OI5G2FUIM OK/t/dRxpntLwx5GQI8S8A4wSy6nU5trrgFpjwRNPvZ4YnwRhxeOFOIsVXH/EUqjJbnM kr63TroFJTpHeRS1Ny7bKJWM29/mDbv8zQ9JsPPzTfu0M2dqZosUe73oOChFBBBplYF1 cs+w== 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=ESoRl4SVY0pOE6ZKle505GcXld13ZmPGzLBjTxBd8EY=; b=ZFzGRsHtwMoSBGbkM3p5u0KHZEc3RN82a0ZXCth2Dr/1El/9ljCjYRdcmOUHKr6EVp gRfu6bk7NDvfyiTlPAVJa2bBB6ioQJomdOBayKR8nPkUbMOQmvHOOLv4fhJnNJ8aURyU 3AU2VhjZt8EsNuzhWXerKd3DUvTOYyKT1vGKVFh66HnvqKvHh0MlWQvKlG3PISyHNmcy wNUB2ynV7ikxQky0VtEwf7MpQOqM+a9QaTMdeoTeDdw5j5pgrr6c+jT69rgx7g3VoRYE 9JlUjL03/QmAzLH50qTHs0reLaRkdW7yr5METq8PT2x7VzxCCxvhiQlhzTSaDyimcGn9 qj9Q== X-Gm-Message-State: AOAM533uNQR4dE5tal+TTTvVdszzRhPv+EI0599dZ777+7ysE06YRP4J oKF7xNKjCeElfKPjHrXyIdo1QKXIFOI= X-Google-Smtp-Source: ABdhPJx5UBYsx/9NTsDESeDO7ewtNIRdKba3GAqqzfS+rn19xPVx2vhFapmIKOL29RhzauWP2Umrfg== X-Received: by 2002:a1c:3c09:: with SMTP id j9mr2278988wma.180.1607513091093; Wed, 09 Dec 2020 03:24:51 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id y68sm3293792wmc.0.2020.12.09.03.24.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Dec 2020 03:24:50 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> <83360g6xlt.fsf@gnu.org> Date: Wed, 09 Dec 2020 11:24:47 +0000 In-Reply-To: <83360g6xlt.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Dec 2020 19:01:18 +0200") Message-ID: <87im9b2pds.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [ We've been CC-ing bug-gnu-emacs@gnu.org for a while. My fault, the typical CC blunder. Wonder how debbugs was dealing with that so gracefully tho. ] Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Cc: bug-gnu-emacs@gnu.org >> Date: Tue, 08 Dec 2020 15:56:49 +0000 >>=20 >> > Can you elaborate on the evidence you found of this non-local exit? >>=20 >> It was evidenced by M-x trace-function process-send-string RET and also >> by substituting the snippet I posted earlier with: > few places we call sys_longjmp, and when it breaks, show the C and > Lisp backtrace from there. Right, so I got this setup, compiled Emacs 27.1 with all debugging flags. I can reproduce it, and even with GDB attached, great. The problem is the breakpoints. If I set breakpoints at _all_ places where we call sys_longjmp(), I risk tearing down my X, which I did a couple of times. So I skip those "dangerous" breakpoints. I'm guessing one of the interesting loci to break is unwind_to_catch in eval.c. Of course that gets called every dang time a signal is thrown, so it's hard for me to catch the precise situation, even if I set up nicely and then call M-x redraw-display, and only then enable the breakpoint. It breaks near immediately, and the `bt` output I get is always from some other function that expectedly signalled an error as part of its normal control flow. (Yeah, maybe I shouldn't be using signals for normal control flow, but that's another matter.) So: 1. I have to find a way to set the unwind_to_catch() breakpoint conditional on some Elisp/near-elisp context, in this case something inside the Elisp function sly-net-send() or Fprocess_send_string. Do you think setting a silly global in Fprocess_send_string() and then checking that as the breakpoint condition would be a good idea? Where would I reset the flag? Is there some C-version of "unwind-protect"? =20=20=20 2. The mysterious long jump may be coming from some other place. I enabled a breakpoint in the sys_longjmp call in quit_throw_to_read_char(), but that's not it, I can reproduce the error and it doesn't break there. Then there are some in image.c loci that I don't think matter much and the one in alloc.c which freezes my X. 3. I set up one of those "tracer" breakpoints for the that you once showed me (how did that go?) They're going to make a LOT of noise, but at least we should be able to register the correct unwind_to_catch() context. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 10:33:49 2020 Received: (at 45117) by debbugs.gnu.org; 9 Dec 2020 15:33:49 +0000 Received: from localhost ([127.0.0.1]:35744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn1TR-0002Tm-B8 for submit@debbugs.gnu.org; Wed, 09 Dec 2020 10:33:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45926) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn1TP-0002TX-6t for 45117@debbugs.gnu.org; Wed, 09 Dec 2020 10:33:48 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49401) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kn1TJ-0002Do-V0; Wed, 09 Dec 2020 10:33:41 -0500 Received: from [176.228.60.248] (port=2492 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kn1TI-0006dq-99; Wed, 09 Dec 2020 10:33:41 -0500 Date: Wed, 09 Dec 2020 17:33:35 +0200 Message-Id: <83k0tr5700.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87im9b2pds.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Wed, 09 Dec 2020 11:24:47 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> <83360g6xlt.fsf@gnu.org> <87im9b2pds.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: 45117@debbugs.gnu.org > Date: Wed, 09 Dec 2020 11:24:47 +0000 > > [ We've been CC-ing bug-gnu-emacs@gnu.org for a while. My fault, the > typical CC blunder. Wonder how debbugs was dealing with that so > gracefully tho. ] It should deal with this just fine, as long as you keep the same Subject line. > If I set breakpoints at _all_ places where we call sys_longjmp(), I risk > tearing down my X, which I did a couple of times. > > So I skip those "dangerous" breakpoints. I'm guessing one of the > interesting loci to break is unwind_to_catch in eval.c. Of course that > gets called every dang time a signal is thrown, so it's hard for me to > catch the precise situation, even if I set up nicely and then call M-x > redraw-display, and only then enable the breakpoint. AFAICT, the only relevant call to sys_longjmp is in eval.c. That is, if we think Emacs signals an error or otherwise throws to top-level. > It breaks near immediately, and the `bt` output I get is always from > some other function that expectedly signalled an error as part of its > normal control flow. One simple method of dealing with that is to make GDB continue immediately after hitting the breakpoint: break eval.c:NNNN commands > bt > continue > end (the ">" prompt is printed by GDB). Then you will have a lot of backtraces, but only the last one will be relevant. This simple method has a disadvantage that it slows down Emacs, and also produces a lot of possibly uninteresting stuff. > 1. I have to find a way to set the unwind_to_catch() breakpoint > conditional on some Elisp/near-elisp context, in this case something > inside the Elisp function sly-net-send() or Fprocess_send_string. > > Do you think setting a silly global in Fprocess_send_string() and > then checking that as the breakpoint condition would be a good idea? > Where would I reset the flag? Is there some C-version of > "unwind-protect"? The C version of unwind-protect is record_unwind_protect. But I think it will be easier to use an existing variable that is usually not touched. For example, you could piggy-back bidi-inhibit-bpa, which is normally nil. On the C level, this is a bool variable bidi_inhibit_bpa, which is normally zero. So, you could wrap the problematic Lisp fragment with (let ((bidi-inhibit-bpa t)) .... ) and then make the breakpoint conditional on that: break eval.c:NNNN if bidi_inhibit_bpa != 0 The advantage of this is that when the let-form unwinds, the variable will be automatically reset (again, if we believe the theory of signal/throw that cause the non-local exit). HTH From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 10:01:11 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 15:01:11 +0000 Received: from localhost ([127.0.0.1]:39001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knNRO-0006ei-VN for submit@debbugs.gnu.org; Thu, 10 Dec 2020 10:01:11 -0500 Received: from mail-wm1-f42.google.com ([209.85.128.42]:51079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knNRN-0006eT-87 for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 10:01:10 -0500 Received: by mail-wm1-f42.google.com with SMTP id c198so4919964wmd.0 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 07:01:09 -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=dsNqdmUUfOe9BR3Of2RAkuD2ALRZf8s2URUaV88yYoM=; b=PcfErnSBhAYyuGG+TO48ZY+unHW4PN74CRCnzRoYv2XExCs9oVMZaFkJLAbH9DPGL1 Qcs6ea75RKyNf8lwNYULpTKDFRpQysMjDe8MtZMlp6BTy7OjXm259tNm8uH0Z4Z6o7vc S0+RZlJLvriSUhws3gDSdAMg4Yh3B67rMImqcltWZVuLP7oVWFACNAn0is3nzDa91EBs fshggw+/PrDyRTrRCFiyROJjd6xLpu0F464BGkC1kNJg7P2bBZnekFuqLlRj06JoIun5 u7157LMHF7DK/Mx3jf6ni19cnOhs3hL6mt5udnIhhk6Buul5YVVYLrpJGV06am8RYWWY RsAA== 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=dsNqdmUUfOe9BR3Of2RAkuD2ALRZf8s2URUaV88yYoM=; b=BizdNYKkcVOTL+4ltq67dWSyjF8rOdUgKycLyzKg14zvotZh6meWzijBO8rRsP0DKm iiakA76AjeFB+ywzsuFPHXgdeEXcvNMvzNXcaszR9pqrYN3nJSmuNVlmLuk8MHwD8aT4 xM2VUu7EohalAj85GWJZ5mx8YwR42uJu0yM7P4HtUTaXbyHVdOPpFEKu3pQnWbRiTS2l KFIvfUEVqDqENDRrhBwNfZQkygP/PFCVsnPSyMDlADLj8CD0MUiMFN9ppR8VBwGIb0ES 3itMIwTxRCkZMWewVEhMrR2EJ/TMYMhuUiMMQOGBV8osO2g2pb/3bdVtJTRUFG9wVtS9 5Caw== X-Gm-Message-State: AOAM531efs2ecLKnqZ3aA+05fhZyqUGvQ3pBg3TerqGm1mA3BFGbmx0G yRnKRCYxopnFjm93UH1p9veVsx2/7u8= X-Google-Smtp-Source: ABdhPJysLin6UFEVKpOWb036U4EFWPZhi8aysEG5lfJHSuOklIPvI+UwqWCeC3ARhc/0BDWvAnijvw== X-Received: by 2002:a7b:cc90:: with SMTP id p16mr8323148wma.105.1607612462013; Thu, 10 Dec 2020 07:01:02 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id j2sm9737225wrt.35.2020.12.10.07.01.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 07:01:00 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> Date: Thu, 10 Dec 2020 15:00:58 +0000 In-Reply-To: <83k0tr5700.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 09 Dec 2020 17:33:35 +0200") Message-ID: <87360d3dud.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > AFAICT, the only relevant call to sys_longjmp is in eval.c. That is, > if we think Emacs signals an error or otherwise throws to top-level. I thought that, but now I'm confused. I'm uncertain about possible, different ways of "exiting non-locally" from a function, which I define by (foo) running and (bar) never running in (progn (foo) (bar)). When that happens, (foo) has exited non-locally. As far as I know, Elisp has no CL-style TAGBODY or GO, right? So indeed I would expect that throw/catch/signal things at the C-level are the only possible responsibles for these situations. > break eval.c:NNNN > commands > > bt > > continue > > end > > (the ">" prompt is printed by GDB). Then you will have a lot of > backtraces, but only the last one will be relevant. This simple > method has a disadvantage that it slows down Emacs, and also produces > a lot of possibly uninteresting stuff. Thanks. That's the "tracer" strategy I remember you telling me. It was useful in the past, not so much here. >> 1. I have to find a way to set the unwind_to_catch() breakpoint >> conditional on some Elisp/near-elisp context, in this case something >> inside the Elisp function sly-net-send() or Fprocess_send_string. >>=20 >> Do you think setting a silly global in Fprocess_send_string() and >> then checking that as the breakpoint condition would be a good idea? >> Where would I reset the flag? Is there some C-version of >> "unwind-protect"? > > The C version of unwind-protect is record_unwind_protect. > > But I think it will be easier to use an existing variable that is > usually not touched. For example, you could piggy-back > bidi-inhibit-bpa, That's an excellent idea, and I've verified that it works. But it didn't help here. Or rather, not in the way I had anticipated. It did help me determine that unwind_to_catch() doesn't seem to be the only responsible for the non-local exit. To be clear, I now have this that I put around the "suspicious" places: (cl-defmacro DEBUG-45117 ((message) &rest body) (declare (indent defun)) (let ((var (cl-gensym))) `(let ((,var nil) (bidi-inhibit-bpa t)) ; for your conditional break trick (unwind-protect (prog1 (progn ,@body) (setq ,var t)) (unless ,var (message ,message)))))) Here's how I use it in sly.el, in the code that's called from the idle timer. (defun sly-net-send (sexp proc) "Send a SEXP to Lisp over the socket PROC. This is the lowest level of communication. The sexp will be READ and EVAL'd by Lisp." (DEBUG-45117 ("SOMETHING in SLY-NET-SEND bailed") (let* ((print-circle nil) (print-quoted nil) (payload (DEBUG-45117 ("ENCODE-CODING-STRING????") (encode-coding-string (concat (sly-prin1-to-string sexp) "\n") 'utf-8-unix))) (string (DEBUG-45117 ("LENGTH-ENCODING????") (concat (sly-net-encode-length (length payload)) payload)))) (DEBUG-45117 ("PROCESS-SEND-STRING?????") (process-send-string proc string))))) I then launch Emacs as I explained earlier: gdb -i=3Dmi --args ~/Source/Emacs/emacs-27/src/emacs -Q \ -L ~/Source/Emacs/sly \ -l sly-autoloads \ -f sly \ --eval "(setq eldoc-idle-delay 0.01)" \ ~/Source/Emacs/sly/slynk/slynk.lisp=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 Then ensure that breakpoints looks more or less like this (a couple more than the one you recommended there.) 1 breakpoint keep y 0x00005555557e2580 in terminate_due_to_= signal at emacs.c:378 2 breakpoint keep y 0x000055555576f4f5 in x_error_quitter a= t xterm.c:10131 3 breakpoint keep y 0x00005555555aa32d in Fredraw_display a= t dispnew.c:3123 breakpoint already hit 1 time 6 breakpoint keep y 0x0000555555966de5 in unwind_to_catch a= t eval.c:1178 stop only if bidi_inhibit_bpa !=3D 0 7 breakpoint keep y 0x000055555580b985 in quit_throw_to_rea= d_char at keyboard.c:10970 stop only if bidi_inhibit_bpa !=3D 0 10 breakpoint keep y 0x0000555555963f1a in call_debugger at = eval.c:283 stop only if bidi_inhibit_bpa !=3D 0 Then 'r' to run, then start the debugging process I explained, basically just scroll up and down in the slynk.lisp file. After a while, in *Messages*, some of these start appearing. ENCODE-CODING-STRING???? SOMETHING in SLY-NET-SEND bailed [sly] [issue#385] likely `process-send-string' exited non-locally from= timer. ... more scrolling ...=20 SOMETHING in SLY-NET-SEND bailed [aly] [issue#385] likely `process-send-string' exited non-locally from= timer. [2 times] Note that ENCODE-CODING-STRING???? is missing from the second observation! In this last session I didn't capture the "PROCESS-SEND-STRING???", but I'm pretty sure I have in the past. It does seem though, that contrary to my original expectation, this is not exclusive to process-send-string, but it happens in normal elisp execution from quickly firing idle timers. Anyway. 1. Shouldn't all of these have triggered the breakpoint?? I'm setting the Elisp/C variable in the macro. I tested the technique separately. 2. Are we sure that no other mechanisms other than throw/catch/signal can trigger a non-local exit (that unwind-protect can still somehow catch?). Thanks for any insight you may have, Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 10:24:00 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 15:24:00 +0000 Received: from localhost ([127.0.0.1]:39089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knNnU-0007JR-CZ for submit@debbugs.gnu.org; Thu, 10 Dec 2020 10:24:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58064) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knNnT-0007JG-N1 for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 10:24:00 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42016) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knNnO-0001ZE-Ha; Thu, 10 Dec 2020 10:23:54 -0500 Received: from [176.228.60.248] (port=2838 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knNnN-000811-R3; Thu, 10 Dec 2020 10:23:54 -0500 Date: Thu, 10 Dec 2020 17:23:33 +0200 Message-Id: <83eejx4rd6.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87360d3dud.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Thu, 10 Dec 2020 15:00:58 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: 45117@debbugs.gnu.org > Date: Thu, 10 Dec 2020 15:00:58 +0000 > > 6 breakpoint keep y 0x0000555555966de5 in unwind_to_catch at eval.c:1178 > stop only if bidi_inhibit_bpa != 0 You have put the breakpoint at the point where sys_longjmp is about to be called, right? But all the unwind forms are already done at that point, so I guess bidi_inhibit_bpa is again zero, and the breakpoint doesn't break. So I suggest to move the breakpoint before the do-while loop in unwind_to_catch: do { /* Unwind the specpdl stack, and then restore the proper set of handlers. */ unbind_to (handlerlist->pdlcount, Qnil); last_time = handlerlist == catch; if (! last_time) handlerlist = handlerlist->next; } while (! last_time); > 1. Shouldn't all of these have triggered the breakpoint?? I'm setting > the Elisp/C variable in the macro. I tested the technique > separately. > > 2. Are we sure that no other mechanisms other than throw/catch/signal > can trigger a non-local exit (that unwind-protect can still somehow > catch?). Let's see if it works to move the breakpoint location, and take it from there. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 11:15:56 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 16:15:56 +0000 Received: from localhost ([127.0.0.1]:39139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knObj-0000DT-9U for submit@debbugs.gnu.org; Thu, 10 Dec 2020 11:15:56 -0500 Received: from mail-wr1-f42.google.com ([209.85.221.42]:40962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knObg-0000D5-5j for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 11:15:54 -0500 Received: by mail-wr1-f42.google.com with SMTP id a12so6060819wrv.8 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 08:15:52 -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=nt4SDdoOufpFRJk4QvYyRD9O83L0KksYQcE88gYvqIg=; b=D1ggWJtYsBaw4aeUy5HhQLTRpRiYlNh8piWQdopR8NyBrAcJnvwiHF6qFHf/Mzs+Fg usC7ZvJEjISehu7apFuaYGg4N3kT0EfGRG2inrRO4EahEauNI+KK93yVLknPZFA9qoH0 fmdJifvPALs/CqpWcB3rkfc2AEzOVx7dezQqxZpPYensnm2H2i5S2irr6rLmWCSQM0n1 9AoJidu4GgpfbR8oKFH6YjsihihwqYWTGpK7CByyUNX8UyLP8WjDmxYa0avmiAT46NNM zZF/318SWqra2lfET3u3xFZ+qF2Zcj2CRKgd4MnkvmW477aPUf6locz4CgzG7XMHPH09 5cYg== 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=nt4SDdoOufpFRJk4QvYyRD9O83L0KksYQcE88gYvqIg=; b=ibtxfzI3t2MX/UeeawdmyIooo9lK83bwB+2GP5SI3xkKOgiA4TsIjMUNfNMnazPBUR V3E9JuhjXFzR7D04nhWY9OOLdZEqs9NOcuYdbRec4Y/OLEVs3DRYbAYul9ClP3JEzi/Y LmMMoCuDkpRUZzXXtIHaxzzZoJlhR3KduWYxNkBMytCu9wouzYxJHOrgqUSaRM+O8EPP Zh55Zinjpcp72tdpkgN5A06Rx7FRCXqef0IwOLweVEh/KnwWpFVpD6wI1eHvN3jmBs3u M6qTSC33Q1TwGpr7B/up2eIuiube2sJGfpH39U813mHAcptIyiaJcuFK3CrLSnxrZbeT J+1w== X-Gm-Message-State: AOAM533OBLHG2AjEMRtMU1GHW8rzzeff32EQWJT4EvkGSiD7x4LTKLp6 Cbo/6nB7ZcQH0liSrdtjCXo7aQ8PNE4= X-Google-Smtp-Source: ABdhPJy6Nh+ukG2s/br8akN37JinSjZWM1EYwRuxIIqPREmGOffoDRG4mMp+tjoSZOsr0EoUuwmnyA== X-Received: by 2002:a05:6000:c9:: with SMTP id q9mr8944860wrx.259.1607616945606; Thu, 10 Dec 2020 08:15:45 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id b73sm10570307wmb.0.2020.12.10.08.15.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 08:15:44 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> Date: Thu, 10 Dec 2020 16:15:42 +0000 In-Reply-To: <83eejx4rd6.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Dec 2020 17:23:33 +0200") Message-ID: <87r1nx1vtd.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Cc: 45117@debbugs.gnu.org >> Date: Thu, 10 Dec 2020 15:00:58 +0000 >>=20 >> 6 breakpoint keep y 0x0000555555966de5 in unwind_to_catc= h at eval.c:1178 >> stop only if bidi_inhibit_bpa !=3D 0 > > You have put the breakpoint at the point where sys_longjmp is about to > be called, right? But all the unwind forms are already done at that > point, so I guess bidi_inhibit_bpa is again zero, and the breakpoint > doesn't break. So I suggest to move the breakpoint before the > do-while loop in unwind_to_catch: > Yes! good idea! though I don't udnerstand why that breakpoint _did_ break when I did (let ((bidi-inhibit-bpa t)) (error "test-error")) Anyway, it seems process_quit_flag is being called and throwing (though I don't see "Quit" in the *Messages*). And didn't you tell me that idle timers run with inhibit-quit =3D t? But inhibit-quit seems to be nil, (which I also confirmed from Elisp.) I looked in the sly source and am quite sure I'm not binding it to nil in that circunstance. Here are two backtraces, I'm going to try just setting inhibit-quit to non-nil forcibly. Jo=C3=A3o (gdb) bt #0 unwind_to_catch (catch=3D0x555556ed0470, type=3DNONLOCAL_EXIT_THROW= , value=3DXIL(0x30)) at eval.c:1167 #1 0x0000555555966e9f in Fthrow (tag=3DXIL(0x2aaa9bb7f060), value=3DXI= L(0x30)) at eval.c:1195 #2 0x0000555555967e6f in process_quit_flag () at eval.c:1523 #3 0x0000555555967ec0 in maybe_quit () at eval.c:1544 #4 0x000055555596bbf0 in Ffuncall (nargs=3D3, args=3D0x7fffffff8a68) a= t eval.c:2767 #5 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556f0e8a4)= , vector=3DXIL(0x555556dc5da5), maxdepth=3Dmake_fixnum(9), args_template=3D= make_fixnum(0), nargs=3D0, args=3D0x7fffffff8f70) at bytecode.c:633 #6 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556dc5e55), na= rgs=3D0, arg_vector=3D0x7fffffff8f70) at eval.c:2990 #7 0x000055555596bd8e in Ffuncall (nargs=3D1, args=3D0x7fffffff8f68) a= t eval.c:2797 #8 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556ef8764)= , vector=3DXIL(0x555556dc0255), maxdepth=3Dmake_fixnum(8), args_template=3D= make_fixnum(257), nargs=3D1, args=3D0x7fffffff9468) at bytecode.c:633 #9 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556dc02d5), na= rgs=3D1, arg_vector=3D0x7fffffff9460) at eval.c:2990 #10 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffff9458) a= t eval.c:2797 #11 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556ef6144)= , vector=3DXIL(0x555556dbf835), maxdepth=3Dmake_fixnum(21), args_template= =3Dmake_fixnum(513), nargs=3D1, args=3D0x7fffffff9ef0) at bytecode.c:633 #12 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556d87a55), na= rgs=3D1, arg_vector=3D0x7fffffff9ee8) at eval.c:2990 #13 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffff9ee0) a= t eval.c:2797 #14 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556f09df4)= , vector=3DXIL(0x555556d1b4b5), maxdepth=3Dmake_fixnum(18), args_template= =3Dmake_fixnum(1025), nargs=3D2, args=3D0x7fffffffa390) at bytecode.c:633 #15 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556d1b545), na= rgs=3D2, arg_vector=3D0x7fffffffa380) at eval.c:2990 #16 0x000055555596c6f2 in apply_lambda (fun=3DXIL(0x555556d1b545), args= =3DXIL(0x555557117b03), count=3D35) at eval.c:2927 #17 0x000055555596a51c in eval_sub (form=3DXIL(0x555557117af3)) at eval= .c:2319 #18 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #19 0x000055555596cf42 in funcall_lambda (fun=3DXIL(0x555557117bd3), na= rgs=3D2, arg_vector=3D0x0) at eval.c:3061 #20 0x000055555596c6f2 in apply_lambda (fun=3DXIL(0x555557117403), args= =3DXIL(0x555557110623), count=3D33) at eval.c:2927 #21 0x000055555596a76b in eval_sub (form=3DXIL(0x555557110613)) at eval= .c:2349 #22 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #23 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557110333)) at eval= .c:2227 #24 0x00005555559643ec in Fif (args=3DXIL(0x555557110353)) at eval.c:417 #25 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557110363)) at eval= .c:2227 #26 0x0000555555964681 in Fprogn (body=3DXIL(0x555557110663)) at eval.c= :462 #27 0x000055555596456a in Fcond (args=3DXIL(0x55555710fc23)) at eval.c:= 442 #28 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fc33)) at eval= .c:2227 #29 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #30 0x00005555559661f9 in FletX (args=3DXIL(0x55555710fc53)) at eval.c:= 919 #31 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fc63)) at eval= .c:2227 #32 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #33 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fc73)) at eval= .c:2227 #34 0x00005555559643ec in Fif (args=3DXIL(0x55555710fca3)) at eval.c:417 #35 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fc93)) at eval= .c:2227 #36 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #37 0x0000555555966771 in Flet (args=3DXIL(0x55555710fcd3)) at eval.c:9= 87 #38 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fce3)) at eval= .c:2227 #39 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #40 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fcf3)) at eval= .c:2227 #41 0x0000555555966f78 in Funwind_protect (args=3DXIL(0x55555710fd23)) = at eval.c:1213 #42 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fd13)) at eval= .c:2227 #43 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #44 0x0000555555966771 in Flet (args=3DXIL(0x55555710fd73)) at eval.c:9= 87 #45 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fd83)) at eval= .c:2227 #46 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #47 0x0000555555946222 in Fsave_excursion (args=3DXIL(0x55555710fda3)) = at editfns.c:842 #48 0x0000555555969e80 in eval_sub (form=3DXIL(0x55555710fd93)) at eval= .c:2227 #49 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #50 0x000055555596cf42 in funcall_lambda (fun=3DXIL(0x55555710fe53), na= rgs=3D0, arg_vector=3D0x0) at eval.c:3061 #51 0x000055555596bea1 in Ffuncall (nargs=3D1, args=3D0x7fffffffb810) a= t eval.c:2809 #52 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x7ffff1d77b2c)= , vector=3DXIL(0x7ffff1d778ed), maxdepth=3Dmake_fixnum(4), args_template=3D= make_fixnum(0), nargs=3D0, args=3D0x7fffffffbcd0) at bytecode.c:633 #53 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x7ffff1d778bd), na= rgs=3D0, arg_vector=3D0x7fffffffbcd0) at eval.c:2990 #54 0x000055555596bd8e in Ffuncall (nargs=3D1, args=3D0x7fffffffbcc8) a= t eval.c:2797 #55 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x7ffff1d77b6c)= , vector=3DXIL(0x7ffff1d77865), maxdepth=3Dmake_fixnum(1), args_template=3D= make_fixnum(0), nargs=3D0, args=3D0x7fffffffc2f0) at bytecode.c:633 #56 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x7ffff1d7783d), na= rgs=3D0, arg_vector=3D0x7fffffffc2f0) at eval.c:2990 #57 0x000055555596bd8e in Ffuncall (nargs=3D1, args=3D0x7fffffffc2e8) a= t eval.c:2797 #58 0x000055555596a8cf in Fapply (nargs=3D2, args=3D0x7fffffffc2e8) at = eval.c:2378 #59 0x000055555596c1b1 in funcall_subr (subr=3D0x555556180000 ,= numargs=3D2, args=3D0x7fffffffc2e8) at eval.c:2848 #60 0x000055555596bd4a in Ffuncall (nargs=3D3, args=3D0x7fffffffc2e0) a= t eval.c:2795 #61 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x7ffff20cbe64)= , vector=3DXIL(0x7ffff20cbd2d), maxdepth=3Dmake_fixnum(10), args_template= =3Dmake_fixnum(257), nargs=3D1, args=3D0x7fffffffc830) at bytecode.c:633 #62 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x7ffff20cbcfd), na= rgs=3D1, arg_vector=3D0x7fffffffc828) at eval.c:2990 #63 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffffc820) a= t eval.c:2797 #64 0x000055555596b549 in call1 (fn=3DXIL(0xd230), arg1=3DXIL(0x5555573= 57de5)) at eval.c:2655 #65 0x00005555557f9db0 in timer_check_2 (timers=3DXIL(0), idle_timers= =3DXIL(0x5555572d5d73)) at keyboard.c:4336 #66 0x00005555557f9f06 in timer_check () at keyboard.c:4398 #67 0x00005555557f7b2a in readable_events (flags=3D1) at keyboard.c:3397 #68 0x0000555555800421 in get_input_pending (flags=3D1) at keyboard.c:6= 806 #69 0x000055555580a12a in detect_input_pending_run_timers (do_display= =3Dtrue) at keyboard.c:10367 #70 0x0000555555a1161a in wait_reading_process_output (time_limit=3D60,= nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3DXIL(0), wait_= proc=3D0x0, just_wait_proc=3D0) at process.c:5707 #71 0x00005555555b31e8 in sit_for (timeout=3Dmake_fixnum(60), reading= =3Dtrue, display_option=3D1) at dispnew.c:6056 #72 0x00005555557f51e0 in read_char (commandflag=3D1, map=3DXIL(0x55555= 72d5e53), prev_event=3DXIL(0), used_mouse_menu=3D0x7fffffffd195, end_time= =3D0x0) at keyboard.c:2738 #73 0x0000555555807fc2 in read_key_sequence (keybuf=3D0x7fffffffd380, p= rompt=3DXIL(0), dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue,= fix_current_buffer=3Dtrue, prevent_redisplay=3Dfalse) at keyboard.c:9553 #74 0x00005555557f07c1 in command_loop_1 () at keyboard.c:1350 #75 0x0000555555967843 in internal_condition_case (bfun=3D0x5555557f032= 3 , handlers=3DXIL(0x90), hfun=3D0x5555557ef8d3 = ) at eval.c:1356 #76 0x00005555557efee4 in command_loop_2 (ignore=3DXIL(0)) at keyboard.= c:1091 #77 0x0000555555966c26 in internal_catch (tag=3DXIL(0xd500), func=3D0x5= 555557efeb3 , arg=3DXIL(0)) at eval.c:1117 #78 0x00005555557efe7e in command_loop () at keyboard.c:1070 #79 0x00005555557ef39a in recursive_edit_1 () at keyboard.c:714 #80 0x00005555557ef59a in Frecursive_edit () at keyboard.c:786 #81 0x00005555557e4fc9 in main (argc=3D11, argv=3D0x7fffffffd808) at em= acs.c:2062 =20=20=20=20=20 Lisp Backtrace: "sly-connection" (0xffff8f70) "sly-send" (0xffff9460) "sly-dispatch-event" (0xffff9ee8) "sly-eval-async" (0xffffa380) "sly-autodoc--async" (0xffffa5d0) "progn" (0xffffa7b0) "if" (0xffffa8f0) "cond" (0xffffaa60) "let*" (0xffffac00) "progn" (0xffffad30) "if" (0xffffae70) "let" (0xffffb050) "progn" (0xffffb180) "unwind-protect" (0xffffb2b0) "let" (0xffffb490) "save-excursion" (0xffffb5f0) "sly-autodoc" (0xffffb818) "eldoc-print-current-symbol-info" (0xffffbcd0) 0xf1d77838 PVEC_COMPILED "apply" (0xffffc2e8) "timer-event-handler" (0xffffc828) (gdb) Here's another one =20=20=20=20 Thread 1 "emacs" hit Breakpoint 3, unwind_to_catch (catch=3D0x555556f35d= 10, type=3DNONLOCAL_EXIT_THROW, value=3DXIL(0x30)) at eval.c:1167 1167 unbind_to (handlerlist->pdlcount, Qnil); (gdb) bt #0 unwind_to_catch (catch=3D0x555556f35d10, type=3DNONLOCAL_EXIT_THROW,= value=3DXIL(0x30)) at eval.c:1167 #1 0x0000555555966e9f in Fthrow (tag=3DXIL(0x2aaa9bb7f060), value=3DXIL= (0x30)) at eval.c:1195 #2 0x0000555555967e6f in process_quit_flag () at eval.c:1523 #3 0x0000555555967ec0 in maybe_quit () at eval.c:1544 #4 0x00005555559ba8d4 in print_object (obj=3DXIL(0x5555572d1044), print= charfun=3DXIL(0), escapeflag=3Dtrue) at print.c:1938 #5 0x00005555559bbced in print_object (obj=3DXIL(0x5555571805e3), print= charfun=3DXIL(0), escapeflag=3Dtrue) at print.c:2122 #6 0x00005555559bbced in print_object (obj=3DXIL(0x555557197333), print= charfun=3DXIL(0), escapeflag=3Dtrue) at print.c:2122 #7 0x00005555559bbced in print_object (obj=3DXIL(0x555557197253), print= charfun=3DXIL(0), escapeflag=3Dtrue) at print.c:2122 #8 0x00005555559bbced in print_object (obj=3DXIL(0x555557196d83), print= charfun=3DXIL(0), escapeflag=3Dtrue) at print.c:2122 #9 0x00005555559b7956 in print (obj=3DXIL(0x555557196b33), printcharfun= =3DXIL(0), escapeflag=3Dtrue) at print.c:1147 #10 0x00005555559b54e7 in Fprin1_to_string (object=3DXIL(0x555557196b33)= , noescape=3DXIL(0)) at print.c:685 #11 0x000055555596c300 in funcall_subr (subr=3D0x555556182840 , numargs=3D1, args=3D0x7fffffff8598) at eval.c:2870 #12 0x000055555596bd4a in Ffuncall (nargs=3D2, args=3D0x7fffffff8590) at= eval.c:2795 #13 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556ec99b4),= vector=3DXIL(0x555556dc5c85), maxdepth=3Dmake_fixnum(5), args_template=3Dm= ake_fixnum(257), nargs=3D1, args=3D0x7fffffff8a50) at bytecode.c:633 #14 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556dc5cc5), nar= gs=3D1, arg_vector=3D0x7fffffff8a48) at eval.c:2990 #15 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffff8a40) at= eval.c:2797 #16 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556f01344),= vector=3DXIL(0x555556e22ed5), maxdepth=3Dmake_fixnum(13), args_template=3D= make_fixnum(514), nargs=3D2, args=3D0x7fffffff8f70) at bytecode.c:633 #17 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556e22f85), nar= gs=3D2, arg_vector=3D0x7fffffff8f60) at eval.c:2990 #18 0x000055555596bd8e in Ffuncall (nargs=3D3, args=3D0x7fffffff8f58) at= eval.c:2797 #19 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556ed6724),= vector=3DXIL(0x555556de7f15), maxdepth=3Dmake_fixnum(8), args_template=3Dm= ake_fixnum(257), nargs=3D1, args=3D0x7fffffff9468) at bytecode.c:633 #20 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556dc9335), nar= gs=3D1, arg_vector=3D0x7fffffff9460) at eval.c:2990 #21 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffff9458) at= eval.c:2797 #22 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556ebfa04),= vector=3DXIL(0x555556de74c5), maxdepth=3Dmake_fixnum(21), args_template=3D= make_fixnum(513), nargs=3D1, args=3D0x7fffffff9ef0) at bytecode.c:633 #23 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556dc9285), nar= gs=3D1, arg_vector=3D0x7fffffff9ee8) at eval.c:2990 #24 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffff9ee0) at= eval.c:2797 #25 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x555556ece464),= vector=3DXIL(0x555556dc0015), maxdepth=3Dmake_fixnum(18), args_template=3D= make_fixnum(1025), nargs=3D2, args=3D0x7fffffffa390) at bytecode.c:633 #26 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x555556dc00a5), nar= gs=3D2, arg_vector=3D0x7fffffffa380) at eval.c:2990 #27 0x000055555596c6f2 in apply_lambda (fun=3DXIL(0x555556dc00a5), args= =3DXIL(0x55555711a753), count=3D35) at eval.c:2927 #28 0x000055555596a51c in eval_sub (form=3DXIL(0x55555711a743)) at eval.= c:2319 #29 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #30 0x000055555596cf42 in funcall_lambda (fun=3DXIL(0x55555711a043), nar= gs=3D2, arg_vector=3D0x0) at eval.c:3061 #31 0x000055555596c6f2 in apply_lambda (fun=3DXIL(0x55555711a053), args= =3DXIL(0x555557113273), count=3D33) at eval.c:2927 #32 0x000055555596a76b in eval_sub (form=3DXIL(0x555557113263)) at eval.= c:2349 #33 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #34 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557112f83)) at eval.= c:2227 #35 0x00005555559643ec in Fif (args=3DXIL(0x555557112fa3)) at eval.c:417 #36 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557112fb3)) at eval.= c:2227 #37 0x0000555555964681 in Fprogn (body=3DXIL(0x5555571132b3)) at eval.c:= 462 #38 0x000055555596456a in Fcond (args=3DXIL(0x555557112873)) at eval.c:4= 42 #39 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557112883)) at eval.= c:2227 #40 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #41 0x00005555559661f9 in FletX (args=3DXIL(0x5555571128a3)) at eval.c:9= 19 #42 0x0000555555969e80 in eval_sub (form=3DXIL(0x5555571128b3)) at eval.= c:2227 #43 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #44 0x0000555555969e80 in eval_sub (form=3DXIL(0x5555571128c3)) at eval.= c:2227 #45 0x00005555559643ec in Fif (args=3DXIL(0x5555571128f3)) at eval.c:417 #46 0x0000555555969e80 in eval_sub (form=3DXIL(0x5555571128e3)) at eval.= c:2227 #47 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #48 0x0000555555966771 in Flet (args=3DXIL(0x555557112923)) at eval.c:987 #49 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557112933)) at eval.= c:2227 #50 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #51 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557112943)) at eval.= c:2227 #52 0x0000555555966f78 in Funwind_protect (args=3DXIL(0x555557112973)) a= t eval.c:1213 #53 0x0000555555969e80 in eval_sub (form=3DXIL(0x555557112963)) at eval.= c:2227 #54 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #55 0x0000555555966771 in Flet (args=3DXIL(0x5555571129c3)) at eval.c:987 #56 0x0000555555969e80 in eval_sub (form=3DXIL(0x5555571129d3)) at eval.= c:2227 #57 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #58 0x0000555555946222 in Fsave_excursion (args=3DXIL(0x5555571129f3)) a= t editfns.c:842 #59 0x0000555555969e80 in eval_sub (form=3DXIL(0x5555571129e3)) at eval.= c:2227 #60 0x0000555555964681 in Fprogn (body=3DXIL(0)) at eval.c:462 #61 0x000055555596cf42 in funcall_lambda (fun=3DXIL(0x555557112aa3), nar= gs=3D0, arg_vector=3D0x0) at eval.c:3061 #62 0x000055555596bea1 in Ffuncall (nargs=3D1, args=3D0x7fffffffb810) at= eval.c:2809 #63 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x7ffff1d77b2c),= vector=3DXIL(0x7ffff1d778ed), maxdepth=3Dmake_fixnum(4), args_template=3Dm= ake_fixnum(0), nargs=3D0, args=3D0x7fffffffbcd0) at bytecode.c:633 #64 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x7ffff1d778bd), nar= gs=3D0, arg_vector=3D0x7fffffffbcd0) at eval.c:2990 #65 0x000055555596bd8e in Ffuncall (nargs=3D1, args=3D0x7fffffffbcc8) at= eval.c:2797 #66 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x7ffff1d77b6c),= vector=3DXIL(0x7ffff1d77865), maxdepth=3Dmake_fixnum(1), args_template=3Dm= ake_fixnum(0), nargs=3D0, args=3D0x7fffffffc2f0) at bytecode.c:633 #67 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x7ffff1d7783d), nar= gs=3D0, arg_vector=3D0x7fffffffc2f0) at eval.c:2990 #68 0x000055555596bd8e in Ffuncall (nargs=3D1, args=3D0x7fffffffc2e8) at= eval.c:2797 #69 0x000055555596a8cf in Fapply (nargs=3D2, args=3D0x7fffffffc2e8) at e= val.c:2378 #70 0x000055555596c1b1 in funcall_subr (subr=3D0x555556180000 , = numargs=3D2, args=3D0x7fffffffc2e8) at eval.c:2848 #71 0x000055555596bd4a in Ffuncall (nargs=3D3, args=3D0x7fffffffc2e0) at= eval.c:2795 #72 0x00005555559f6eb4 in exec_byte_code (bytestr=3DXIL(0x7ffff20cbe64),= vector=3DXIL(0x7ffff20cbd2d), maxdepth=3Dmake_fixnum(10), args_template=3D= make_fixnum(257), nargs=3D1, args=3D0x7fffffffc830) at bytecode.c:633 #73 0x000055555596ca8b in funcall_lambda (fun=3DXIL(0x7ffff20cbcfd), nar= gs=3D1, arg_vector=3D0x7fffffffc828) at eval.c:2990 #74 0x000055555596bd8e in Ffuncall (nargs=3D2, args=3D0x7fffffffc820) at= eval.c:2797 #75 0x000055555596b549 in call1 (fn=3DXIL(0xd230), arg1=3DXIL(0x55555735= 6765)) at eval.c:2655 #76 0x00005555557f9db0 in timer_check_2 (timers=3DXIL(0), idle_timers=3D= XIL(0x555557181453)) at keyboard.c:4336 #77 0x00005555557f9f06 in timer_check () at keyboard.c:4398 #78 0x00005555557f7b2a in readable_events (flags=3D1) at keyboard.c:3397 #79 0x0000555555800421 in get_input_pending (flags=3D1) at keyboard.c:68= 06 #80 0x000055555580a12a in detect_input_pending_run_timers (do_display=3D= true) at keyboard.c:10367 #81 0x0000555555a1161a in wait_reading_process_output (time_limit=3D60, = nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3DXIL(0), wait_p= roc=3D0x0, just_wait_proc=3D0) at process.c:5707 #82 0x00005555555b31e8 in sit_for (timeout=3Dmake_fixnum(60), reading=3D= true, display_option=3D1) at dispnew.c:6056 #83 0x00005555557f51e0 in read_char (commandflag=3D1, map=3DXIL(0x555557= 1619d3), prev_event=3DXIL(0), used_mouse_menu=3D0x7fffffffd195, end_time=3D= 0x0) at keyboard.c:2738 #84 0x0000555555807fc2 in read_key_sequence (keybuf=3D0x7fffffffd380, pr= ompt=3DXIL(0), dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue, = fix_current_buffer=3Dtrue, prevent_redisplay=3Dfalse) at keyboard.c:9553 #85 0x00005555557f07c1 in command_loop_1 () at keyboard.c:1350 #86 0x0000555555967843 in internal_condition_case (bfun=3D0x5555557f0323= , handlers=3DXIL(0x90), hfun=3D0x5555557ef8d3 )= at eval.c:1356 #87 0x00005555557efee4 in command_loop_2 (ignore=3DXIL(0)) at keyboard.c= :1091 #88 0x0000555555966c26 in internal_catch (tag=3DXIL(0xd500), func=3D0x55= 55557efeb3 , arg=3DXIL(0)) at eval.c:1117 #89 0x00005555557efe7e in command_loop () at keyboard.c:1070 #90 0x00005555557ef39a in recursive_edit_1 () at keyboard.c:714 #91 0x00005555557ef59a in Frecursive_edit () at keyboard.c:786 #92 0x00005555557e4fc9 in main (argc=3D11, argv=3D0x7fffffffd808) at ema= cs.c:2062 =20=20=20=20 Lisp Backtrace: "prin1-to-string" (0xffff8598) "sly-prin1-to-string" (0xffff8a48) "sly-net-send" (0xffff8f60) "sly-send" (0xffff9460) "sly-dispatch-event" (0xffff9ee8) "sly-eval-async" (0xffffa380) "sly-autodoc--async" (0xffffa5d0) "progn" (0xffffa7b0) "if" (0xffffa8f0) "cond" (0xffffaa60) "let*" (0xffffac00) "progn" (0xffffad30) "if" (0xffffae70) "let" (0xffffb050) "progn" (0xffffb180) "unwind-protect" (0xffffb2b0) "let" (0xffffb490) "save-excursion" (0xffffb5f0) "sly-autodoc" (0xffffb818) "eldoc-print-current-symbol-info" (0xffffbcd0) 0xf1d77838 PVEC_COMPILED "apply" (0xffffc2e8) "timer-event-handler" (0xffffc828) (gdb)=20 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 11:29:22 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 16:29:22 +0000 Received: from localhost ([127.0.0.1]:39155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knOoj-0000YY-QS for submit@debbugs.gnu.org; Thu, 10 Dec 2020 11:29:22 -0500 Received: from mail-wm1-f50.google.com ([209.85.128.50]:36359) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knOog-0000YL-Lg for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 11:29:19 -0500 Received: by mail-wm1-f50.google.com with SMTP id y23so5959165wmi.1 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 08:29:18 -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=vx/950Oz3YXRRGJdlEAPlGsa+rerZLrZ98GkIvI9PvU=; b=W/uPy0paSCvlS4yhO79S7cx6JQNspLcXA/wUglNPLxKKgl/k+cli1Oq+GvRVnTylLh XmqiNtDi4kHiLtEQchr5LklCuvxsZiPVs3gV+wq0LtkUbuH84YJ8kGf48kBIYxO9XUhS AZWM15Xph0CicMYaMFGdV0IYlFzQ3hdMen+Qa9/io2W8w/ZAE2kSOcVhQhclPPT3+s1H 6CUe5OXFkqmmo0RP2d8XctaV7QEKwGQnOJ1ZB7Jl42o2ujTcbiwZOP1edIlQ3/dPBOst 8yCse4hHDZnehs9uXizm5W/OnV0cyk6P8q+Dig7D7oCcF0r7HX5SwTYfJzj93W55Eq6m APSQ== 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=vx/950Oz3YXRRGJdlEAPlGsa+rerZLrZ98GkIvI9PvU=; b=pyiQU+X43BixPVquV0GhAUN60ynV9Ix+4qN1iI3Z7EU4Rvxy8Tg/26b5RuQpoDa8GT 9hVZlQDkxPEisRbnw7u3ZG9gq5EjzB6ds1FIoD2/kfcxfyW0NH459/VBhzejLjWrJgfW PvVOKYiXO/gwLmdewOdM05Ffby2rISfIx8ubd0NrQcmT8MEjCz/kMvnY4AwJYeeouT6q dIbut4Vs4PBIoLayiP/zosHVv5AvZw+mVA30oVq9WSf8D1hjVMmEzYMF7/lsJYJwUV2X /dC3Qq1mg/FH4BIf+kP9oCI/O/UN3DVyyL39F8YvNxhzw1EiW47PHBNc8JLRdHRlvIXh sxPw== X-Gm-Message-State: AOAM530pl0JWUf61Y9LnCtHSScRwUvN69KYKpailNu1J/ZnrYcGFCqOv qcke/OFRpXb1gd+9zYs+M08mk1A+brA= X-Google-Smtp-Source: ABdhPJzNn8KAFyoh/JkpH/aXEGDyLKDgpY11xkh/hFUkJ6Egohb8H+zAIsQMOHh66c+Qg0yribNmpQ== X-Received: by 2002:a1c:df0a:: with SMTP id w10mr9255361wmg.114.1607617752591; Thu, 10 Dec 2020 08:29:12 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id j2sm10068208wrt.35.2020.12.10.08.29.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 08:29:11 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii , Stefan Monnier Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> Date: Thu, 10 Dec 2020 16:29:09 +0000 In-Reply-To: <87r1nx1vtd.fsf@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Thu, 10 Dec 2020 16:15:42 +0000") Message-ID: <87mtyl1v6y.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > Eli Zaretskii writes: > >>> From: Jo=C3=A3o T=C3=A1vora >>> Cc: 45117@debbugs.gnu.org >>> Date: Thu, 10 Dec 2020 15:00:58 +0000 >>>=20 >>> 6 breakpoint keep y 0x0000555555966de5 in unwind_to_cat= ch at eval.c:1178 >>> stop only if bidi_inhibit_bpa !=3D 0 >> >> You have put the breakpoint at the point where sys_longjmp is about to >> be called, right? But all the unwind forms are already done at that >> point, so I guess bidi_inhibit_bpa is again zero, and the breakpoint >> doesn't break. So I suggest to move the breakpoint before the >> do-while loop in unwind_to_catch: >> > > Yes! good idea! though I don't udnerstand why that breakpoint _did_ break > when I did > > (let ((bidi-inhibit-bpa t)) (error "test-error")) > > Anyway, it seems process_quit_flag is being called and throwing (though > I don't see "Quit" in the *Messages*). And didn't you tell me that idle > timers run with inhibit-quit =3D t? But inhibit-quit seems to be nil, > (which I also confirmed from Elisp.) I looked in the sly source and am > quite sure I'm not binding it to nil in that circunstance. Aha! I found the culprit. It is eldoc.el. It seems to be a longstanding policy to call Eldoc backends with `with-no-input`. This is obviously badly problematic for aynchronous backends. Stefan, I think this change has to go. Now that we have proper (or more proper) async support in eldoc.el, we shouldn't need these tricks: just use a timer or a process or sth. Else we must super clearly document that the eldoc-documentation-function can stop at any moment for whatever reason and that it's probably a good idea to bullet-proof your async code with inhibit-quit=3Dt. In the meantime I'll do that, forcing inhibit-quit back to t in sly-autodoc.el. That should fix it. Thanks a lot, Eli! Really amazing. Jo=C3=A3o commit 12e922156c86a26fa4bb2cb9e7d2b3fd639e4707 Author: Stefan Monnier Date: Tue Dec 4 18:15:44 2018 -0500 * lisp/emacs-lisp/eldoc.el: Let the user interrupt the search =20=20=20=20 (eldoc-print-current-symbol-info): Use while-no-input and non-essential. diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el --- a/lisp/emacs-lisp/eldoc.el +++ b/lisp/emacs-lisp/eldoc.el @@ -360,6 +365,4 @@ - (and (or (eldoc-display-message-p) - ;; Erase the last message if we won't display a new one. - (when eldoc-last-message - (eldoc-message nil) - nil)) - (eldoc-message (funcall eldoc-documentation-function))))) + ;; Only keep looking for the info as long as the user hasn't + ;; requested our attention. This also locally disables inhibit-qu= it. + (while-no-input + (eldoc-message (funcall eldoc-documentation-function))))))) From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 11:42:20 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 16:42:20 +0000 Received: from localhost ([127.0.0.1]:39160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knP1I-0000sl-8G for submit@debbugs.gnu.org; Thu, 10 Dec 2020 11:42:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knP1F-0000sX-Cn for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 11:42:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42822) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knP1A-0004yv-5D; Thu, 10 Dec 2020 11:42:12 -0500 Received: from [176.228.60.248] (port=3879 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knP19-00020U-Eh; Thu, 10 Dec 2020 11:42:11 -0500 Date: Thu, 10 Dec 2020 18:41:51 +0200 Message-Id: <83blf14nqo.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87r1nx1vtd.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Thu, 10 Dec 2020 16:15:42 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: 45117@debbugs.gnu.org > Date: Thu, 10 Dec 2020 16:15:42 +0000 > > Anyway, it seems process_quit_flag is being called and throwing (though > I don't see "Quit" in the *Messages*). And didn't you tell me that idle > timers run with inhibit-quit = t? Yes, see for yourself, this fragment from timer_check_2, which calls timer-event-handler: specbind (Qinhibit_quit, Qt); <<<<<<<<<<<<<<<<<<< call1 (Qtimer_event_handler, chosen_timer); Vdeactivate_mark = old_deactivate_mark; timers_run++; unbind_to (count, Qnil); > But inhibit-quit seems to be nil (which I also confirmed from > Elisp.) I guess some code called from the timer resets inhibit-quit to nil? You could put a watchpoint on Vinhibit_quit and see who does that. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 12:21:02 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 17:21:02 +0000 Received: from localhost ([127.0.0.1]:39201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knPcj-0001qw-VT for submit@debbugs.gnu.org; Thu, 10 Dec 2020 12:21:02 -0500 Received: from mail-ej1-f53.google.com ([209.85.218.53]:36177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knPcg-0001qW-1r for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 12:21:00 -0500 Received: by mail-ej1-f53.google.com with SMTP id lt17so8443295ejb.3 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 09:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NWkrn3lpP2xmq35P29GZabTxci/emIPuuwkrqkRX5J0=; b=B/O7UASvKyHYEMEnPSPTKQaG9ncv9dh8AeSFyOnyksLIyhLPN13csNFaMsQovMm5tj Rv20orCRLeG77LBYIzG4exNClZDLdsXDDL8hvElLaqwMSyPfCU8irLvibKYMsYe9dsrc eOD40Qo8rSCfQTvtrrDv2bjHf2qyoGWME5JnrVwd4w6KMNHD2xaSQmqCdg0tvl4+SA4+ 53vKLj42+/79UpSrd8OnqjSHhngSv8fxDliPTeLXtTd6ilN9LqrOJQGeMmTm3vR/53n4 JpNcYkYNe2eeUmM7O0aed7Hb11qRR4lZ0dXYUlWJSbjddmOiSDL9AoAf5tjODE0ro0U9 ocDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NWkrn3lpP2xmq35P29GZabTxci/emIPuuwkrqkRX5J0=; b=uSEp2ajSrWP6yPh79DqIZaXCXmhdH+vpVd3m20GSL8K2jIJwUiAUQ3ItBcTefQVEMT E8nN13TyXPaInZ0sYzj7PJkB+U0Gx7xKhyLBmhf1StLwnxX3ntjqwxoQsfA6w33zdlmO fHaf8DYjPBqu8hqSVCi3WwD+4a/uuFQ7l6HjZcrA+5qzc9ZZ+V+HCROmVslb6vPjcnTs ek08eXSgj8aKobN1VndAcXmkOdnNOxDbLAzBI6QDMRonfEWD4vxXEcQSwugZEXveSmrA ByyZIFpUVH/6ojsmbTd9THnb8KH5TY2r1Givc8tSr4lZppOuBOC1zoUhug7DTvn9yiPA KOrQ== X-Gm-Message-State: AOAM532x7fN8dmdUXaVNV/jMwXW+LcmT4cA5YzYdjP6oOOsS+EzMzIQ0 O5MIGGTBNTQN+P5PHsOUimP9E0j3d1jZ8Q== X-Google-Smtp-Source: ABdhPJzdq26Q+UC9ykgSJ+d8+HPYv7/PKjfOjBYUcu37J7wsTdePm5T5V8YGUeMTQMMdIJ6VLqPQTQ== X-Received: by 2002:a17:906:da08:: with SMTP id fi8mr7278921ejb.517.1607620851941; Thu, 10 Dec 2020 09:20:51 -0800 (PST) Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id t8sm4968843eju.69.2020.12.10.09.20.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 09:20:51 -0800 (PST) Subject: Re: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Eli Zaretskii , Stefan Monnier 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> From: Dmitry Gutov Message-ID: <464f8218-4cc0-9752-a904-e5a226a0aa69@yandex.ru> Date: Thu, 10 Dec 2020 19:20:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <87mtyl1v6y.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 10.12.2020 18:29, João Távora wrote: > Stefan, I think this change has to go. Now that we have proper (or more > proper) async support in eldoc.el, we shouldn't need these tricks: just > use a timer or a process or sth. Not everybody uses the async support. This was a good change, and I'm taking advantage of it in at least one external package. I wonder how hard it would be to fix the async support not to be hindered by it. Also note that that this form could be useful for the asynchronous route as well: after the user has send some new input, we don't really want to process the "old" eldoc requests anymore, those responses should be ignored. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 12:51:50 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 17:51:50 +0000 Received: from localhost ([127.0.0.1]:39226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQ6X-0002cQ-JW for submit@debbugs.gnu.org; Thu, 10 Dec 2020 12:51:49 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQ6R-0002c8-TI for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 12:51:47 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8287A440CF6; Thu, 10 Dec 2020 12:51:38 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 16B30440D3A; Thu, 10 Dec 2020 12:51:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607622697; bh=N17HVIVuju9Poh1yoVnxxbLjp/L6+wKoeUClhiYUPAU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=CyBwfTtuOomCi5hoEDQzaseIz82ufsyHCWQbzk28Si5xYLQDiZ6LILGGMoalHLMFf 92r95xfcAVbJj08fWuK/BXLz5bGAK5rc9577AI2+QqoN254AK5y7c9GC0AJk8qz0c5 kgktjfwOsi5WiLHanYHx8eWQU/LIBrAprbsEkcdM3jGjibdgGwHrqpnXdv/czlsSzK Gz+BfesWC6ScUUNMt0CO+b1QN9LoSK3miU6YYnaYIYtHhoSA3lnqe5LdavMyBU/Com /fJV2xDYci1tU/NEPrcU0jnWr83wZvOShQiyme0DtHQ1wd+9wnLQYMh9XgfA1D5Rv8 xrCZZf2tEx2wA== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CD18F12036E; Thu, 10 Dec 2020 12:51:36 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> Date: Thu, 10 Dec 2020 12:51:35 -0500 In-Reply-To: <87mtyl1v6y.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Thu, 10 Dec 2020 16:29:09 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.077 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Aha! I found the culprit. It is eldoc.el. It seems to be a > longstanding policy to call Eldoc backends with `with-no-input`. This > is obviously badly problematic for aynchronous backends. Maybe "obviously" so from a pragmatic point of view, but in a theoretical sense, I don't see why: for async backends, the `while-no-input` should only apply to the "first chunk" of computation which launches the async subprocess (or communication) and it seems OK to abort this first chunk if the user hits a key while it's executing. So maybe the better answer is to improve the implementation of `while-no-input` so it doesn't abort here. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 13:06:14 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 18:06:14 +0000 Received: from localhost ([127.0.0.1]:39233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQKU-0002zX-2E for submit@debbugs.gnu.org; Thu, 10 Dec 2020 13:06:14 -0500 Received: from mail-io1-f47.google.com ([209.85.166.47]:37884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQKR-0002zE-9w for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 13:06:13 -0500 Received: by mail-io1-f47.google.com with SMTP id p187so6478484iod.4 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 10:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LKumcR0oOmYCJ46w+U8T422nUl2oGnJ55nLsgfHzYSw=; b=IiotPc/D7bU0pstBceAIaBlh6Hzo+6HznVbWrEMHom4D+QrBO0Q6vv19/Oauzli54L R+b7xLElYJwtoSl9cNHNqqo0nHBoA8LWFU2Q+gRIruSzxLUme3nVjTt7vnnNuEIqO4h3 ZEdIChWqbdsJZZK/tBpjZWNjwOC2T4d5/oNDTcTLDHnU6mGrVD6JvZwqk7LoySibIAF8 m7yNVH3jPF7ueFOiITr1A6xbiP3AJUKM13xMRtM4wZaVAKyorhuWoq7S4bbBkJYfKlW+ ALKfAGHvLu3tBS8BZc0mDAac2wlu9ld79w3NzFRWcvMIOj2JqbWVzKtgqCxgkwVNwiQB Wtrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LKumcR0oOmYCJ46w+U8T422nUl2oGnJ55nLsgfHzYSw=; b=jsf+LqLaLlsepgohaWO/rQOxTv2yBH8t9c7WWTOZG+d2rffTXUnKHjJblwph67Zubg tfJDMDLrYWK8hQc6lWBGBbet1Olbctzuph32X96kTRAAmUdsUtlwpW6193Q+jXyeKFQm qSoZhfM12iU6p3Kr5PTDEKu11R04YjsIjX16kmnnIlggvhGzkgSwT3aQBUFGpPvrpjl3 rCb3mSlxumsrLa1QLSE7mZCy/GBUHQsfiiw5vSOqJest7722po5auMuzlVhq6Tky9bMU VAbyxo6fBwzG3esFTwnlpyBBS1oxeLTgV3IIWwTD/VdY1hiUwWnAGK5mIepkMKVofg2H XviA== X-Gm-Message-State: AOAM531IZRB/NXWINgbu7ulZUFhSPO3vWxBz/fNbJRnMvHghWAxPZRAq U3oomxYiCYffX5TtV94SRKN66sBPb52w7A+eChs= X-Google-Smtp-Source: ABdhPJzxfC1JbugM8XBp4GwLJA5cnNGB7opGKR9eap9IGLLZZ4MQFh7czvWvex5YyJiq9zd1ynt3kWTdrA80ytIiqiA= X-Received: by 2002:a05:6602:2b01:: with SMTP id p1mr9504528iov.156.1607623565560; Thu, 10 Dec 2020 10:06:05 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 10 Dec 2020 18:05:54 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Dec 10, 2020 at 5:51 PM Stefan Monnier w= rote: > > > Aha! I found the culprit. It is eldoc.el. It seems to be a > > longstanding policy to call Eldoc backends with `with-no-input`. This > > is obviously badly problematic for aynchronous backends. > > Maybe "obviously" so from a pragmatic point of view, but in > a theoretical sense, I don't see why: 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). To find that suitable continuation it has to be added to the continuation registry (step B). I'd say step A and B have to be atomic, whatever the order. If you interrupt between A and B you get either an unexpected reply. If you interrupt between B and A you get a stale leftover continuation. Both are inconsistent state, in my opinion. There are workarounds for all of this, but I think this while-no-input isn't conceptually sound there, for this reason. 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. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 13:38:18 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 18:38:18 +0000 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 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 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) 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== 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) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> Date: Thu, 10 Dec 2020 13:37:59 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 10 Dec 2020 18:05:54 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.077 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 13:48:43 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 18:48:43 +0000 Received: from localhost ([127.0.0.1]:39275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQza-00043H-GA for submit@debbugs.gnu.org; Thu, 10 Dec 2020 13:48:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knQzZ-000435-9r for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 13:48:41 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45731) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knQzT-0006QR-RV; Thu, 10 Dec 2020 13:48:35 -0500 Received: from [176.228.60.248] (port=3726 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knQzT-0002dM-9w; Thu, 10 Dec 2020 13:48:35 -0500 Date: Thu, 10 Dec 2020 20:48:16 +0200 Message-Id: <83y2i533bj.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 10 Dec 2020 13:37:59 -0500) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: joaotavora@gmail.com, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 45117@debbugs.gnu.org > Date: Thu, 10 Dec 2020 13:37:59 -0500 > > 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, ...). Let me remind you that we nowadays have while-no-input-ignore-events. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 13:50:47 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 18:50:47 +0000 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 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 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) 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) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Stefan Monnier Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> Date: Thu, 10 Dec 2020 18:50:33 +0000 In-Reply-To: (Stefan Monnier's message of "Thu, 10 Dec 2020 13:37:59 -0500") Message-ID: <87h7ot1ona.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 14:44:58 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 19:44:58 +0000 Received: from localhost ([127.0.0.1]:39317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRs2-0007UE-43 for submit@debbugs.gnu.org; Thu, 10 Dec 2020 14:44:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRry-0007Tz-N0 for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 14:44:57 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46698) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knRrs-0007y0-PS; Thu, 10 Dec 2020 14:44:48 -0500 Received: from [176.228.60.248] (port=3172 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knRrr-00046Y-ST; Thu, 10 Dec 2020 14:44:48 -0500 Date: Thu, 10 Dec 2020 21:44:28 +0200 Message-Id: <83v9d930pv.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87h7ot1ona.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Thu, 10 Dec 2020 18:50:33 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: monnier@iro.umontreal.ca, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: Eli Zaretskii , 45117@debbugs.gnu.org > Date: Thu, 10 Dec 2020 18:50:33 +0000 > > there's a presumably reason we bind inhibit-quit to t in timers > (Eli?) The reason, quite obviously, is to prevent user's C-g from aborting the timer function. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 14:46:13 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 19:46:14 +0000 Received: from localhost ([127.0.0.1]:39322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRtF-0007Wy-HF for submit@debbugs.gnu.org; Thu, 10 Dec 2020 14:46:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRtD-0007Wm-S0 for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 14:46:12 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 23A34440BC6; Thu, 10 Dec 2020 14:46:06 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3860C440A43; Thu, 10 Dec 2020 14:46:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607629564; bh=inlGEbgZsTNAOckb9T9XVzsWx6okGI0A42CTLLU/v54=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=lkx32tqnbiBsEiLVdGJLK2yO9QDZpw/fdAlxJC1BcYun5ZoNLqEhC/mJLO/3hmV20 TG055F4oJJHHRo647WGesY5/ULxnq+JdC4mT6Nq6YAkTu/cJat6x3OQ4tGXBkWY3tx 8XTuLIchXDHAdQ/32eCLrqQW69MOw/XEYGJsoatDPMrc8iqGLULKBwT3zusHeKG3pQ tZrtcFNgrbvE931+VzsKWUN+GL+gVStLzpafNyZbgGbwVA8X5f+bOzNqj8bhUhIlS3 6IyymVmjKdQkhAQ6/ca4AbH55+wcRhH6vKoskKXP63JDJC92646vxJMNklveE3mek9 hkM86lEKHttMg== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BE69E1203AB; Thu, 10 Dec 2020 14:46:03 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> Date: Thu, 10 Dec 2020 14:46:02 -0500 In-Reply-To: <87h7ot1ona.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Thu, 10 Dec 2020 18:50:33 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.076 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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. No, I was no presuming such a simple model, actually. I was really thinking about "send data to the LSP server then get some answer a second or more later". >> 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. That's just for lack of a vocabulary to say abstractly what I meant. I understand that in many cases you may want to keep the subprocess (and pipe) open, in which case you'll have to do something else, but that "something" will depend on lots of details of the circumstance. >> 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, we bind inhibit-quit there because when the users hit C-g they presumably have no idea whether a timer or process filter happens to be running right now, so they don't actually mean "stop this timer" but something entirely different (such as run the command `keyboard-quit`). Note that in return we expect timers and process filters to run only for a very short amount of time, so that we can still react to C-g promptly. > Doing that for her in the library is violating the premise of timer > functions as one knows them. The contract is different for timer functions than it is for eldoc functions, yes. This is because the expectation is that eldoc functions may run for a non-negligible amount of time. Maybe we should change that so it's up to the individual eldoc function to use `while-no-input` if it needs it, but I'm not sure we've reached that conclusion yet ;-) > 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". OK, so `while-no-input` did its job correctly in your case. Good. Now the next question is: given that the user has hit `C-n` how should we make sure Emacs responds to it as soon as possible even though it's currently in the middle of sending a command to an LSP subprocess? Is this "sending" expected to never take a long time (in which case maybe using `inhibit-quit` could be the better answer)? What's the alternative: what could the Elisp code do to abort the communication as quickly as possible (without leaving the subprocess in an inconsistent state and without forcing a costly restart of that subprocess)? If the protocol doesn't offer any way to abort a command, maybe it could stash the rest of the data to be sent on some list of pending data so they'll be sent later asynchronously (and remember that the answer to that command is probably to be ignored because the user has moved on)? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 14:47:29 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 19:47:29 +0000 Received: from localhost ([127.0.0.1]:39326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRuS-0007Yx-VC for submit@debbugs.gnu.org; Thu, 10 Dec 2020 14:47:29 -0500 Received: from mail-il1-f173.google.com ([209.85.166.173]:35313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRuQ-0007Yj-Lh for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 14:47:27 -0500 Received: by mail-il1-f173.google.com with SMTP id t9so6461976ilf.2 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 11:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fi55dNkN7XavLMk0lSGbH/sWBw62NFtHy0xEd+IHhrc=; b=ZmMuEDEUM9j3dvf9ES17dS9b7ftpTTP51m6Db2z1bWGPiQb6LfqwyhqwwUPZACSNyB RRwZahFOuud138WSwW4AulIuYWPLYYCiyNJHXftGxwBtedt5xcxUmpMnHPpDXNxvaLOH aXoKSoPAAebjlI1ZxrvqHHbIINRsK4YFV4Yincu0xbJ0PuGzxX/oIoacZLimPC/8T/+U qgqfLm1KQKFIkFoPqF0csJhcnPixtNhk6ZxQexv1tSV8QtbY/VNTuGuTGu1cg8hNze9S IBt19y0+/puJfpxVJtxJ50zFdJH6QxjpIM8FAXraGXK9nkDn6EHqofWpvR/I1vnPwmFo FjHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fi55dNkN7XavLMk0lSGbH/sWBw62NFtHy0xEd+IHhrc=; b=k2IZaSQ21U46aP82sxqEYTeSyJ+eeKDxaDjSvDdMHhiVX/Oqgex6iV7RLm4uWdvBHf ks1G9HF5+LuLO0I2AFvNG+0ea26l/6QQj10gndZhNuFgQG5iKZWOTVLrdDOpj/e2/ent J+HOFL5AP+PMN4e0cf0Y04VmOkVQ7+ln6PUEOV+ENX9f0KtUKPfDgkHpod8fP3qSrhle aoC0JEqhNSa6B0nVl2MI16lofSXQkFBLeZMlSMJ1dxgcOmUZQWFDW+7qIfypqAeP04CQ upaXmt5yrwpnQQulfX2TLBpg/NFh0Cd6QQbtMNe5uKJzmH/xZfCl9iTIHHsPz4gj4Ta/ Zslw== X-Gm-Message-State: AOAM5308v3rFFdGprNwKLY6a282r9Yg459uhgSI9UVDmMkmbJ4IoYHdB IfYta8Vj2QFoeAdgUL/nx2Rc5HcX9gRzNudhCSc= X-Google-Smtp-Source: ABdhPJxRdmEy71xUYBn9IisDiAiVg2n1T4Ymm8lse1UwO3KX4njHCGo6PbvZR5kjR/XHHISj+lROz7WfSJUp46bDbks= X-Received: by 2002:a05:6e02:19cd:: with SMTP id r13mr10160334ill.199.1607629640900; Thu, 10 Dec 2020 11:47:20 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <83v9d930pv.fsf@gnu.org> In-Reply-To: <83v9d930pv.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 10 Dec 2020 19:47:08 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Stefan Monnier , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Dec 10, 2020 at 7:44 PM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Cc: Eli Zaretskii , 45117@debbugs.gnu.org > > Date: Thu, 10 Dec 2020 18:50:33 +0000 > > > > there's a presumably reason we bind inhibit-quit to t in timers > > (Eli?) > > The reason, quite obviously, is to prevent user's C-g from aborting > the timer function. I agree, but playing devil's advocate, can you expand on the rationale for that? Why shouldn't timer functions be abortable? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 14:55:35 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 19:55:35 +0000 Received: from localhost ([127.0.0.1]:39335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knS2I-0007kM-Mw for submit@debbugs.gnu.org; Thu, 10 Dec 2020 14:55:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knS2G-0007k9-Fh for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 14:55:32 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46938) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knS2B-0003Y8-0i; Thu, 10 Dec 2020 14:55:27 -0500 Received: from [176.228.60.248] (port=3827 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knS2A-0005KZ-81; Thu, 10 Dec 2020 14:55:26 -0500 Date: Thu, 10 Dec 2020 21:55:06 +0200 Message-Id: <83sg8d3085.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 10 Dec 2020 19:47:08 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <83v9d930pv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: monnier@iro.umontreal.ca, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Thu, 10 Dec 2020 19:47:08 +0000 > Cc: Stefan Monnier , 45117@debbugs.gnu.org > > > The reason, quite obviously, is to prevent user's C-g from aborting > > the timer function. > > I agree, but playing devil's advocate, can you expand on the > rationale for that? Why shouldn't timer functions be abortable? I think that's the wrong question. The right question is how probable is it that the user presses C-g to abort a timer function that just happens to run at this very moment. I think the answer is "extremely improbable". It is much more probable that C-g was meant for something else, some activity that is much more evident to the user. Like getting out of the minibuffer after deciding that the command does not need to be invoked after all, for example. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 14:58:33 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 19:58:33 +0000 Received: from localhost ([127.0.0.1]:39339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knS5B-0007oU-8M for submit@debbugs.gnu.org; Thu, 10 Dec 2020 14:58:33 -0500 Received: from mail-il1-f175.google.com ([209.85.166.175]:33763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knS58-0007oG-VR for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 14:58:31 -0500 Received: by mail-il1-f175.google.com with SMTP id y9so6511298ilb.0 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 11:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=I4/qp5HYsYZRWo8wsMHdfP7G+cY1+Z+SLsaZuupQHv0=; b=PreGb3NOD3RPsK1vqE7lAPkIzPLEhIb9SW2ZOY0ItfYAK/1zNdLaxlh1LBaBp8Qq04 xCl/ID0JMRm9NbWZHjnbZczNzm6UY8qqcJkjfU0I90ozkA46cUWjP5+4gKa96qZApI2T TelMJNZEtnAhY7Op93UeDQhmThY+yYo3BqrhX974udPUNBBKqhU3UvJboAnGFLCYVD4b IuBBCuJoWigYiI/WYdglCE1Np6+NLokQ+Q17eRx15fxje/rqSsgKoV64fhpoI6B89hPC hAOe7cHx4DyYKX7e54bWOiUNQj8N050ch43lkhjD8yO5Ma2zz7yG+HCpRT3r78I5drKh 2gDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=I4/qp5HYsYZRWo8wsMHdfP7G+cY1+Z+SLsaZuupQHv0=; b=m6oafh3+roU19uZh5/w2zWG383kaKjk4Dp0GtinqI3nKzXoRFCif0xcZ1FGI78Rp1G +kL4U9cizfeKYSvTYUNQXGAWBQASYEEJ53wrG8bIgLRcxx5d5up664FK9CLiX4U+vDEh 4AGG/26U+3JpFgsM9HLWwqlHp0o92QIGmbxgU4ctk1xOadjnCXZY8ZKD53L7lGWiUaVN 0CZSEIckWN3XTpFr4NEYwOVACUmtnYlTznKLr+yMFzLBW5V6zDCbCCvB8H5b0eYlcsmt dNyomVKOmk+KXdrq9NbOcTKoSaWfjHu5BlFuhBHOYsqZdDibeb/X219OWp5c5sM7E+jF XTzw== X-Gm-Message-State: AOAM531EfZ+dHpfI7bcO9WiMzHn2p4OPvyUfuLq+4nAQrtHsrXvYb0+F rGuFhY330lk1KN43XNJIj9QwUwxxmou615/Y+sw= X-Google-Smtp-Source: ABdhPJzOuDwwNMDH2+rhHYWYCrqxtOBGwgKlb+Am3rz+wqcf3SL9fMlPul2IhR6iQnHvssNOi4U5wvd3Se2aUafJWpE= X-Received: by 2002:a92:da82:: with SMTP id u2mr10633950iln.137.1607630305226; Thu, 10 Dec 2020 11:58:25 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <83v9d930pv.fsf@gnu.org> <83sg8d3085.fsf@gnu.org> In-Reply-To: <83sg8d3085.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 10 Dec 2020 19:58:12 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Stefan Monnier , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Dec 10, 2020 at 7:55 PM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Thu, 10 Dec 2020 19:47:08 +0000 > > Cc: Stefan Monnier , 45117@debbugs.gnu.org > > > > > The reason, quite obviously, is to prevent user's C-g from aborting > > > the timer function. > > > > I agree, but playing devil's advocate, can you expand on the > > rationale for that? Why shouldn't timer functions be abortable? > > I think that's the wrong question. The right question is how probable > is it that the user presses C-g to abort a timer function that just > happens to run at this very moment. I think the answer is "extremely > improbable". It is much more probable that C-g was meant for > something else, some activity that is much more evident to the user. > Like getting out of the minibuffer after deciding that the command > does not need to be invoked after all, for example. I see. Yes it makes sense. But Stefan is arguing that some "special" timer functions should be abortable by mere input. And that changes thoses odds considerably. But at the same time, it doesn't change the fact, as you well put it, that that input is _not_ meant for the timer function. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:12:23 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 20:12:23 +0000 Received: from localhost ([127.0.0.1]:39366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSIZ-0008AX-D5 for submit@debbugs.gnu.org; Thu, 10 Dec 2020 15:12:23 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:42630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSIW-0008AJ-Qa for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 15:12:21 -0500 Received: by mail-wr1-f43.google.com with SMTP id m5so6784871wrx.9 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 12:12:20 -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=gxXakKvIdJWdBqKzd/UhoxYCpHBuYS8NWCVtCoc/SXA=; b=NVpafzTi+05WsurmTdqyR1SerCUA9xzrWuVer/kacwARpqErJzX/6TJg0Dd340cVKM yC/e8ZI5VqPgmQDiwD3V4/K9sBnZQ53Jd1CCKNQfYhtL8JFpmuBFi84TeeIZTfO0MAes cNccGKmW63qelBgshr+bGbYsATEkVC8CGFl3lZ+uNbxUC13KiazRRx51dva7na1dkRBD 56uXbfGzNy0zT7HGAgbDdLac1mqS2R4RzyQklCUkG7gsxZrtxVbLToFtkq0P9UUK6jGi j8lsQS2INvDadyy5b7EaheCZgq+u95gl4o6Es1LTNa/su5VDbgewQsTK/MlLk9YC5E/K Ilig== 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=gxXakKvIdJWdBqKzd/UhoxYCpHBuYS8NWCVtCoc/SXA=; b=JoOtoSWiHMdsql5paV4a3oI285RjcuRSGyyHyXHOBwUsSNMewXoHdGC058BuI2lHLU /wTDxnhKgFoHlUhI13+pQXisn/SZ7pqrwFPADQaBO6eKSaltILuKLsr98M4hOlb6sklG id0/feMtOGPK9MmP3LL/BK+jFz3ycqvdM+Ps+ZQD08sVuJmmwT1PQr96+4RouXTmShBo ZqmobQjXAAH/T2NNNiVXYeSddM+uIiTYY304UUzQDKbo8XUMn69uIdiCTVGnf1do7t7g oRtuIXgxi6gejHBl80O3/d8/YYAVJEwv5KYMgikGsIXb5pXUp8G1+udyBGY74hH5PTWH 6WdA== X-Gm-Message-State: AOAM533MK1XvwtUvmy6ufhyi50CCyBg7geBDpQiqAcVUPI+mQGzfez/t d8xJlAUINsWLhGH0681LNeJAqLfqhBg= X-Google-Smtp-Source: ABdhPJxl4C3ACF213fzpLYdyCOExabRyg5DrdHWgMVE83aShFRdMNSsS/B5pgPtw6kioGX0Tqx/FvQ== X-Received: by 2002:adf:9cc6:: with SMTP id h6mr10032997wre.341.1607631134434; Thu, 10 Dec 2020 12:12:14 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id o17sm11783645wrg.32.2020.12.10.12.12.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 12:12:12 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Stefan Monnier Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> Date: Thu, 10 Dec 2020 20:12:11 +0000 In-Reply-To: (Stefan Monnier's message of "Thu, 10 Dec 2020 14:46:02 -0500") Message-ID: <87czzh1kv8.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >>> 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. > > No, I was no presuming such a simple model, actually. I was really > thinking about "send data to the LSP server then get some answer > a second or more later". Right, so in LSP it's perfectly possible to send three requests in a row, say reqX, reqY and reqZ and get three replies in a completely different order repZ, repX, repY. How to you match each reply to each request? >>> 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. > > That's just for lack of a vocabulary to say abstractly what I meant. > I understand that in many cases you may want to keep the subprocess (and > pipe) open, in which case you'll have to do something else, but that > "something" will depend on lots of details of the circumstance. process_send_string may send things in "bunches", I read in the docstring, but it will not (and should not) be interrupted. At least I see no reason to. When it returns, sending should be done. Either that or it should exit loudly with an error that one can catch, in which case one should retry the whole thing. >>> 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, we bind inhibit-quit there because when the users hit C-g they > presumably have no idea whether a timer or process filter happens to be > running right now, so they don't actually mean "stop this timer" but > something entirely different (such as run the command `keyboard-quit`). I see, and you you think it is different for "input something", because that in ElDoc, would in principle invalidate the context of the documentation request. But that is not always so. And I think it's too eager of ElDoc to try to do that so early and so brutally. It's better to leave it to the callback handlers, which we have now. That's a much safer spot to know if the answer we just got still makes sense. Or if we're in a hurry, we let the backend know asap. > Note that in return we expect timers and process filters to run only for > a very short amount of time, so that we can still react to C-g > promptly. Fine, and so they should. Much like Flymake stuff. That's in the contract :-) > The contract is different for timer functions than it is for eldoc > functions, yes. This is because the expectation is that eldoc functions > may run for a non-negligible amount of time. Why do you have that expectation? Any particular example in the wild? > Maybe we should change that so it's up to the individual eldoc function > to use `while-no-input` if it needs it, but I'm not sure we've reached > that conclusion yet ;-) It was, after all, the status quo after you changed it for 27.1. Perhaps you had a rationale? >> 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". > > OK, so `while-no-input` did its job correctly in your case. Good. > Now the next question is: given that the user has hit `C-n` how should > we make sure Emacs responds to it as soon as possible even though it's > currently in the middle of sending a command to an LSP subprocess? > > Is this "sending" expected to never take a long time (in which case > maybe using `inhibit-quit` could be the better answer)? That's what I did, yes. Yes, it's expected to be quick or fail fast. > What's the alternative: what could the Elisp code do to abort the > communication as quickly as possible (without leaving the subprocess in > an inconsistent state and without forcing a costly restart of that > subprocess)? If the protocol doesn't offer any way to abort a command, > maybe it could stash the rest of the data to be sent on some list of > pending data so they'll be sent later asynchronously (and remember that > the answer to that command is probably to be ignored because the user > has moved on)? The protocol could offer an optional abort() switch, yes. ElDoc would raise a flag and say: "hey backends, what you were doing is now useless". We'd see about the implementation, there is likely more than one approach, but a dynamic variable accessed by an (eldoc-aborted-p) seems easiest. I personal don't know of many places where I would use it, or where it would bring an advantage in terms of speed. For example, in responsive completion, I've been doing fine with discarding loads and loads of carefully prepared, now invalid, completions. Fine in terms of speed/responsiveness. But maybe one wishes to save power, which is quite legitimate. Bottom line is, in my opinion, this ElDoc-to-backend abort signal should be controlled, it shouldn't be an unhandleable kill signal. That's asking for trouble. I'd be very suprised if the SLIME people don't start getting this too after they upgrade to 27.1. And maybe the CIDER and Elpy people too? Don't know about Eglot, actually, but I think it's possible yes. All depends on `eldoc-idle-delay`. If it's a low value, it's much much more likely. Since we start with 0.5, we should be OK. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:14:31 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 20:14:31 +0000 Received: from localhost ([127.0.0.1]:39370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSKd-0008Di-00 for submit@debbugs.gnu.org; Thu, 10 Dec 2020 15:14:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46714) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSKZ-0008DT-3Z for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 15:14:30 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47254) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knSKT-0000ul-DS; Thu, 10 Dec 2020 15:14:21 -0500 Received: from [176.228.60.248] (port=4986 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knSKS-0001JQ-Kn; Thu, 10 Dec 2020 15:14:21 -0500 Date: Thu, 10 Dec 2020 22:14:01 +0200 Message-Id: <83r1nx2zcm.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 10 Dec 2020 19:58:12 +0000) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <83v9d930pv.fsf@gnu.org> <83sg8d3085.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: monnier@iro.umontreal.ca, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Thu, 10 Dec 2020 19:58:12 +0000 > Cc: Stefan Monnier , 45117@debbugs.gnu.org > > > I think that's the wrong question. The right question is how probable > > is it that the user presses C-g to abort a timer function that just > > happens to run at this very moment. I think the answer is "extremely > > improbable". It is much more probable that C-g was meant for > > something else, some activity that is much more evident to the user. > > Like getting out of the minibuffer after deciding that the command > > does not need to be invoked after all, for example. > > I see. Yes it makes sense. But Stefan is arguing that some "special" timer > functions should be abortable by mere input. That makes sense mainly for idle timers. Or for timer functions that take a lot of time to execute (something that generally shouldn't happen in the first place). But while-no-input cannot abort its caller, so as long as the body of while-no-input can handle being interrupted, that is okay. > And that changes thoses odds considerably. But at the same time, it > doesn't change the fact, as you well put it, that that input is > _not_ meant for the timer function. I think if a timer function should be interruptible by input, that function should itself call while-no-input. It is not the job of outside code to interrupt bad timers by aborting them by these measures. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:16:20 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 20:16:20 +0000 Received: from localhost ([127.0.0.1]:39374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSMO-0008H6-Jf for submit@debbugs.gnu.org; Thu, 10 Dec 2020 15:16:20 -0500 Received: from mail-il1-f178.google.com ([209.85.166.178]:44435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSMM-0008Gs-5y for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 15:16:19 -0500 Received: by mail-il1-f178.google.com with SMTP id r17so6531186ilo.11 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 12:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=y1xWb7zM2oJPtFd2gCInqLJ+PH48/wGDklUt7HI2YnY=; b=N1RgpRM5LWTdGBieND7Z1DvRBing9BXjy5L4SErbwtx14hQ4xmFkXUP0l3T/QwZMA9 bcBKdj3vAHCEZSa+Ow5LylMd9+8HbUO8FDtbSH464NckAsHpEu37kX4Qtv5KN+DH2OIC 9tAiSLgV1SRjYFB5fo9r9zDLyU7xD9mE50O/NVQGdDA0SP96PCXQMa/2s7DMbWXxbRDN o7wbhNLu13b3L6HGtyJI9cSsKpybEp6skGwYEoiw/3XwhEjjst+xO3cIQrKUGqqo+/jk 6Em93l2uNdg/K3Znf5/30k2QVkQ1Z1HbQ+/VH+cXup2USjZErmngc3+p01X2oQI5FtZi NxFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=y1xWb7zM2oJPtFd2gCInqLJ+PH48/wGDklUt7HI2YnY=; b=B5mkKt2QYVULU2PpWXUVc6pzJ+z91F7lxn6cio/5qPp9r1LbE7CWCPm1HaNHuWvrFu +GTcpoGeB2d/lU3XDsTFVjmS6U1vI8okDL4mePjStTPdwyzOIfGsbfokmYAM5A4o4LQ0 tsJUzgymtlr6X1/NE8sdqlgwbXmEFgJy4jPdFok+9Qac0sZifQDXpunjnLUeh96Vn/ac wFdpWCEiLOPDQCLNmSyziG0T67uZgGidzfOHe/momEym9qD6qkNIiqGnXiFWbgra+16f AIfHmtcEmX2UGaBqNP7XCFJ46LH9erKKpE0vim2v5hIti3QAO+4kzwH0vjaYfDdNsiQX 7y+A== X-Gm-Message-State: AOAM531EjF0IYGRhzCT5shVQ7pEofdyemxyvudSOjXqBksqRIHO1d8VT xtHK29Jojwc5AnCtwUj9M17gLjo2pwVT210BwxQcZvvd X-Google-Smtp-Source: ABdhPJxeYPyOaTSM9b88Wsrl9/1wWjXOHug7V3tvEBpa/++L4cC7ONOQvU3wttk/1KC4r6IHDaDMRwu82NNC1DY2oQY= X-Received: by 2002:a92:c682:: with SMTP id o2mr10840443ilg.97.1607631372383; Thu, 10 Dec 2020 12:16:12 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <83v9d930pv.fsf@gnu.org> <83sg8d3085.fsf@gnu.org> <83r1nx2zcm.fsf@gnu.org> In-Reply-To: <83r1nx2zcm.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 10 Dec 2020 20:15:59 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Stefan Monnier , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Dec 10, 2020 at 8:14 PM Eli Zaretskii wrote: > I think if a timer function should be interruptible by input, that > function should itself call while-no-input. It is not the job of > outside code to interrupt bad timers by aborting them by these > measures. I think that's my view, exactly. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:37:48 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 20:37:48 +0000 Received: from localhost ([127.0.0.1]:39413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knShA-0000Lp-4m for submit@debbugs.gnu.org; Thu, 10 Dec 2020 15:37:48 -0500 Received: from mail-ej1-f43.google.com ([209.85.218.43]:46977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSh8-0000Lb-NK for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 15:37:47 -0500 Received: by mail-ej1-f43.google.com with SMTP id bo9so9209909ejb.13 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 12:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=D6c9OWh14pi0cgxfk7tSKFoOktoCWmoIYIv7uqHZTgU=; b=CbbJSpkpIMeeUFL0mZqv4sZvTknzSjyeYtRVlRE3Hxr1DzYdOLyx8H6Km/kjI7t3qp tVJukyXbe2C+sR3WUbueU7y/ViL4GKQVc6kGMwYVXsfALb7hGkYasG3Nl8EWQYwWIvTs LYW85wMu/WPgzRYbNAkcwyIUzTfs72DoqEAWBq5zT9jT5Qhmm7g1TJMqfTEuumcfTOxz 2ZxubYzUwD9D0Zt7ZHFYGLi/nIf+A7hx5tDLdqdUF5vNhZOgkCG0/yBTRFy/l5ORprV2 VVu2GLWJMUh3dEbZyLoQTdwrP2ZFMjm2pqpaUfH6KQlXDxe3YTonDUtVjxeN0sX+sE83 rupQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D6c9OWh14pi0cgxfk7tSKFoOktoCWmoIYIv7uqHZTgU=; b=Auhf2JHNU1caOGuSth0hw/s8UV0l/yVFp05w243N0rrgMHcp8a0MrpGg0QMJmbXUKU w7poYmbJdH/R7F6dnKUDVowdk9cPXfjjU/RE2Epqo+KwYsTQt53U107WnmE7hqwgLN/e ZF6Ru5GezNonoC0jkZDz3RyC45Ya3kxWHrFxDUpDWzPIhrnMRsa21A5prRqwdW76qYmb Fe2tmqZs6Y6FmdrSlervemF/nPIq1fqSZl7b7K2xG8Tn043fVYb9rWOlvMUVKbe/hnHo WfNBNvbzz3pXfq3J1YOSrv80LDOLOCHQWFF4hARhlnFl7m2q9rXIMwkD4lhrX/2AYek6 KICw== X-Gm-Message-State: AOAM531JLzjbCCex4l1sgZOKOPwIFqKX/DCisAuWwTKDefjFH5VHYDmv naVG0ePWghFSlOYSdfvcYphIbwVL8tpVmg== X-Google-Smtp-Source: ABdhPJyK0BBqunsv8dNPsRY9QrQWk1npqPHef2lx5dyQsHc7hyMt6sFSvUbP5T3WpLGjwTFMm8LDJQ== X-Received: by 2002:a17:906:3099:: with SMTP id 25mr8025746ejv.321.1607632660400; Thu, 10 Dec 2020 12:37:40 -0800 (PST) Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id op5sm5049794ejb.43.2020.12.10.12.37.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 12:37:39 -0800 (PST) Subject: Re: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Eli Zaretskii , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= 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> <87h7ot1ona.fsf@gmail.com> <83v9d930pv.fsf@gnu.org> <83sg8d3085.fsf@gnu.org> <83r1nx2zcm.fsf@gnu.org> From: Dmitry Gutov Message-ID: <9bd70ee6-d612-7eaa-2ccc-04a75d2bd285@yandex.ru> Date: Thu, 10 Dec 2020 22:37:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <83r1nx2zcm.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45117 Cc: monnier@iro.umontreal.ca, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 10.12.2020 22:14, Eli Zaretskii wrote: > That makes sense mainly for idle timers. This applies to Eldoc, surely. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:43:27 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 20:43:27 +0000 Received: from localhost ([127.0.0.1]:39418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSmc-0000U4-Sa for submit@debbugs.gnu.org; Thu, 10 Dec 2020 15:43:27 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSma-0000Tq-VC for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 15:43:25 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9134E440A50; Thu, 10 Dec 2020 15:43:19 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E6D43440A48; Thu, 10 Dec 2020 15:43:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607632997; bh=2iiFWdy62NubXLPgAsOkDG9FhWiO10Gpv+jXHfwewxk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=D3wdmTJOP2nzTFnHHfEVMXH2tAzIcUdw4bqz+H4skoswaiyIAF5XWPkNZ/7JkG6ML o8YYks+BeVb4e5MBpuqdS7XYk4IxXe8W4C5bHBDrnoR6iGp1GT15gy/VqckMUpC56L 7L+Urjpkfo2rP9TNdUlffDGs6c2/Jzsaddbva3y3YrC7/wgqSk8k4jnOxlwQv5BcTc Es8Tz4bPdKCnMmKKa2hk5moP1RT1fsI0vlDjQtW6bXBS9+Li6PVLcz2/tG2D2BgLrG HeqWxY7SLN602ILeqrT/J+NtcGZ3gRDjkF5B/73ttXcv0SrWH6GkdTkCPYt1pbfEQJ Tv+VYYJetp9ZQ== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B16AF1200C3; Thu, 10 Dec 2020 15:43:17 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> Date: Thu, 10 Dec 2020 15:43:16 -0500 In-Reply-To: <87czzh1kv8.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Thu, 10 Dec 2020 20:12:11 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.076 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> No, I was no presuming such a simple model, actually. I was really >> thinking about "send data to the LSP server then get some answer >> a second or more later". > Right, so in LSP it's perfectly possible to send three requests in a > row, say reqX, reqY and reqZ and get three replies in a completely > different order repZ, repX, repY. How to you match each reply to each > request? I assume there's some "request-id" mechanism. Not sure what this has to do with this discussion, OTOH. > process_send_string may send things in "bunches", I read in the > docstring, but it will not (and should not) be interrupted. Indeed, I believe it should not be aborted in the middle by `while-no-input` (it would be a bug, because the `process-send-string` API doesn't offer any way to know what has been or hasn't been sent in that case). >> Indeed, we bind inhibit-quit there because when the users hit C-g they >> presumably have no idea whether a timer or process filter happens to be >> running right now, so they don't actually mean "stop this timer" but >> something entirely different (such as run the command `keyboard-quit`). > I see, and you you think it is different for "input something", because > that in ElDoc, would in principle invalidate the context of the > documentation request. Indeed for eldoc we know that if there is user input, the current request can be dropped on the floor because its result shouldn't be displayed anyway. In contrast in the general case of timers we don't know whether user-input affects the usefulness of running the timer. > But that is not always so. And I think it's too eager of ElDoc to try > to do that so early and so brutally. It's better to leave it to the > callback handlers, which we have now. That's a much safer spot to > know if the answer we just got still makes sense. Or if we're in > a hurry, we let the backend know asap. You might be right: the result of the current request sent to the LSP could still be useful for the next eldoc-idle-time cycle, indeed. >> The contract is different for timer functions than it is for eldoc >> functions, yes. This is because the expectation is that eldoc functions >> may run for a non-negligible amount of time. > Why do you have that expectation? Any particular example in the wild? Good question. > It was, after all, the status quo after you changed it for 27.1. > Perhaps you had a rationale? I probably did, but ... can't remember and wasn't clever enough to write it in the commit message :-( Maybe to accommodate those backends which needed async operation but had to live within the confines of the previously limited eldoc API? Maybe the maintainer of eldoc.el will prefer to undo this change, then ;-) ? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 15:55:23 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 20:55:23 +0000 Received: from localhost ([127.0.0.1]:39428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSyB-0000lv-9a for submit@debbugs.gnu.org; Thu, 10 Dec 2020 15:55:23 -0500 Received: from mail-ed1-f42.google.com ([209.85.208.42]:37478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knSy5-0000lc-GU for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 15:55:21 -0500 Received: by mail-ed1-f42.google.com with SMTP id cm17so7039110edb.4 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 12:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Xm1dTW/BL/lkuCQClr3uRY0e5rBZSUKyBTisMZ0kJSo=; b=Ci+CrjoXpbfHCxkLwKEWsYXsfbj3i6ywQBrErkVKIu6/yK1pG+bKASQpmQSmpBnFDc 2vS/Fq1XvLzaztNN9/0TeULAqOWIurSKARk508RCwh2OdgHbM+pM+kfujcJu6RcB1NJZ 2KnD0thaBqYc4xB5kTXU6e+GuKmbJSW6i3s3VNjSLQbFqJ0GfMSSL4go8FUwCei+9U/9 PCMiOVTFJblJtQvbtkZ5YDYm1QmAj5WJaD0FAfghMBHEe0KbM6mi3S6p0UtNG3XryL+h YP6l9j39uRiAx8UH00hkKN/XLgSRKGHvc2f34/FXAC0oJnU6uE4sO3j8Nri2GBHrYnGD mwhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xm1dTW/BL/lkuCQClr3uRY0e5rBZSUKyBTisMZ0kJSo=; b=af1EQdyT5eqgBTZFpu/QJGrRFNDbnLMNB612j5vaEvCiSCOVcseD0UREcPz6NIh8s3 GgoWvudAvStuKQSQ/P66ESF0lyLr3/NU5p6o7awsIx5zNSgnYpZuPNIPz5OIw+gXTS95 z64X+1VEGCXcC/jcxcmJWPxotxm4Q5pUqZfKFmeXL5ddAsGUDny0dSSV2eHcPb9dF61f bccKqYQBKPm7XOe122Z7nyTNQK2MK7ApUOnld6QM5khTNjBm3PW277Lj5j3n0QgecNqB sTwk0hMNVQ09PfeWyOA25FyTnET9UcYTK4NVPVpjntHWJZJ45vdMjMa0SEhfQmBP8PiG Og+g== X-Gm-Message-State: AOAM531HyMgysEknaKnT6Ozu2RGBjZJQxKquvLKQUZCpf4Km3hHWGPfa nWcSNushZeRgUeGFvXbVQZrTyNbtnYM9iw== X-Google-Smtp-Source: ABdhPJzSbTUdzLLc95AUNcMy3XGcMocJW8wFTEV+5JJ33KyLtMPOIKb/2Xwen51zEK+pfDosz4sIXQ== X-Received: by 2002:aa7:c652:: with SMTP id z18mr8298448edr.60.1607633711372; Thu, 10 Dec 2020 12:55:11 -0800 (PST) Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id bq20sm5091998ejb.64.2020.12.10.12.55.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Dec 2020 12:55:10 -0800 (PST) Subject: Re: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Stefan Monnier , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> From: Dmitry Gutov Message-ID: Date: Thu, 10 Dec 2020 22:55:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45117 Cc: 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 10.12.2020 22:43, Stefan Monnier wrote: >> It was, after all, the status quo after you changed it for 27.1. >> Perhaps you had a rationale? > I probably did, but ... can't remember and wasn't clever enough to write > it in the commit message:-( Both you and Joao can search your email archive for the message titled Re: [Emacs-diffs] scratch/octave-eldoc-fixes 1ad0826 1/2: Prevent accept-process-output with quit inhibited in octave.el05. sent on 05.12.2018, 01:19 EET (I think that's the timezone). There was a small discussion there, with just 3 participants. Not sure why it wasn't conducted in public. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 16:16:16 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 21:16:16 +0000 Received: from localhost ([127.0.0.1]:39452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knTIN-0002N6-Ga for submit@debbugs.gnu.org; Thu, 10 Dec 2020 16:16:16 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:46789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knTII-0002Ew-1T for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 16:16:13 -0500 Received: by mail-wr1-f48.google.com with SMTP id l9so6927783wrt.13 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 13:16:10 -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=bZyzODt8CYUt/roB3Vhonh2Q9ITu51FaI5PiZTyhh2Y=; b=B8yZGTVNniAAKryo+/v2oXvvyAAdBKMk6WJOmZxppGUrJNUPpUPxHPiHBhW6Sp16+e ozV2pcHJk2c4i1J0FSgRU95GDLnPGL79CKeBPnw5+sPMRmpzMd3Qo/kwOcg82x0mNjbb 7MP7MtDgu2mj5VVdl0gs+k7ndzk5XlSMqln4nbTg1B1uypbNcC9hxodjVncBC8eF1vlF 5Gi+j9TA4kagAS7L9cvxmrRqVCjZm88TXPZF9pesQs1jLneggcF41aV8QgP9kvdp2ZIP 82eZPyVZKk4PduM5Lx0modXcz4rbrGYIHmJen2N06AaZa1QNM3rjNgnhqhFhxclO3bjT fJwA== 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=bZyzODt8CYUt/roB3Vhonh2Q9ITu51FaI5PiZTyhh2Y=; b=TIQrQpMwczLsYBDT+0I6npZpulqlSpgYtuDPb4beyAEtP1H3pR0+BlKARs7NlGzawK bqx8ZWZekgXVACFfkFMFJcSkrkB5M21QT2TABT4dSO/EmFfohVwkudbhHYLPCt/J3bFx w6bH7pVGqJN1wUWBflD7ZeIn9n+cDC7L5opT9wr09Wu9gSrldzeKmq/7g12js8vDVqdR 3imecKxSOU494e7BHWZUm75qeUQOv3NtKWFAbW9lGXNNq+yMzG2qgx7wfzvsGYhDVopt KBk7A9g1uDwM/D5JNGJNefIyZ84N8DgHa6siwb7Zdk8JQZUwMwfT6E7joFLPGeqpZwSb U92w== X-Gm-Message-State: AOAM53398cUlNjyS8FKIs9ah5co8iooNLsHv8VtlSXcxKQBMhRWFAF2F yVaZn0mkt07Rw36fHGJ4gtl6KUO5wpI= X-Google-Smtp-Source: ABdhPJxZggHNRQWNmdbFgohM0D27LDcIevs+drKRqgVGmN0jIUEoclxIsorNi47B2AT0nbo2evny4Q== X-Received: by 2002:adf:a29d:: with SMTP id s29mr10248504wra.272.1607634963889; Thu, 10 Dec 2020 13:16:03 -0800 (PST) Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id b73sm11800404wmb.0.2020.12.10.13.16.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 13:16:03 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Stefan Monnier Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> Date: Thu, 10 Dec 2020 21:16:00 +0000 In-Reply-To: (Stefan Monnier's message of "Thu, 10 Dec 2020 15:43:16 -0500") Message-ID: <878sa51hwv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >>> No, I was no presuming such a simple model, actually. I was really >>> thinking about "send data to the LSP server then get some answer >>> a second or more later". >> Right, so in LSP it's perfectly possible to send three requests in a >> row, say reqX, reqY and reqZ and get three replies in a completely >> different order repZ, repX, repY. How to you match each reply to each >> request? > > I assume there's some "request-id" mechanism. Not sure what this has to > do with this discussion, OTOH. Right, a request-id mechanism. The request must be registered atomically with process_send_string. If you interrupt in between, you have inconsistent requests (either registered request-id's for which no actual request was fired, or requests which were fired for which no request-id's were registered). Client code can detect/prevent these interruptions, but it's clumsy. And may cost the dev many hours to understand what is up. Shouldn't be default IMO. >> process_send_string may send things in "bunches", I read in the >> docstring, but it will not (and should not) be interrupted. > > Indeed, I believe it should not be aborted in the middle by > `while-no-input` (it would be a bug, because the `process-send-string` > API doesn't offer any way to know what has been or hasn't been sent in > that case). Agree. >> But that is not always so. And I think it's too eager of ElDoc to try >> to do that so early and so brutally. It's better to leave it to the >> callback handlers, which we have now. That's a much safer spot to >> know if the answer we just got still makes sense. Or if we're in >> a hurry, we let the backend know asap. > > You might be right: the result of the current request sent to the LSP > could still be useful for the next eldoc-idle-time cycle, indeed. Yes, it's only an heuristic. >>> The contract is different for timer functions than it is for eldoc >>> functions, yes. This is because the expectation is that eldoc functions >>> may run for a non-negligible amount of time. >> Why do you have that expectation? Any particular example in the wild? > Good question. :-) >> It was, after all, the status quo after you changed it for 27.1. >> Perhaps you had a rationale? > > I probably did, but ... can't remember and wasn't clever enough to write > it in the commit message :-( > Maybe to accommodate those backends which needed async operation but had > to live within the confines of the previously limited eldoc API? Likely, yes. But which one of those were the "blocking" type? Because even with the limited API, SLY/SLIME were just calling eldoc-message from the process filter. Which is equivalent to what we have now in terms of sync. In fact, to keep backward compatibility, I haven't touched this part of SLY at all. Anyway, you must have done it for some other slow synchronous, wait-for-the-retval backend. That hypothetical backend will hurt if we take back the while-no-input. OTOH that hypothetical backend can now upgrade to a much better API. > Maybe the maintainer of eldoc.el will prefer to undo this change, > then ;-) ? Who's that? ;-) But OK, eldoc.el is now distributable independently so we have good defense against this. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 17:48:33 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 22:48:33 +0000 Received: from localhost ([127.0.0.1]:39541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knUjg-0005gT-Nr for submit@debbugs.gnu.org; Thu, 10 Dec 2020 17:48:32 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knUje-0005gF-Nv for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 17:48:31 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 23363440A43; Thu, 10 Dec 2020 17:48:25 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 96CF9440BEB; Thu, 10 Dec 2020 17:48:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607640503; bh=3IqGa+IpWDQea5Khl8LDtDVIGT2wjvkQaXAE4dTfEz0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Ly89KvfB5JfwrSVuCuLH78U6n+qsED0R35yiEZd6nzufTLTOyjF0NjevzqEf4jakB xW63bU2swKSk8c1WYl+7xE18htcRLOoX4reSgLtNLsONmRO4lpbYaZlEzDOOhBWdO/ ySUlfAUzp01Qq3cM9gjahnajU7hbZhpsKPmSx/kxS3pzFXpn4KLqf43jY+SLIx2XNK sWfd3lGzfBaJKesHdC513gU3aMM5tEp5zagJRPg+d3GqNaZVkI2WjfqlXDkUjd9VG4 P6l/jOppBc/a6VpeRJhOb+MdH009RnPMp8kZ8Z7ve3+XBu1peAaWi9HW+e326VbVvK q8l5h6+RKQrvA== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5B668120371; Thu, 10 Dec 2020 17:48:23 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> Date: Thu, 10 Dec 2020 17:48:22 -0500 In-Reply-To: (Dmitry Gutov's message of "Thu, 10 Dec 2020 22:55:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.076 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> It was, after all, the status quo after you changed it for 27.1. >>> Perhaps you had a rationale? >> I probably did, but ... can't remember and wasn't clever enough to write >> it in the commit message:-( > > Both you and Joao can search your email archive for the message titled > > Re: [Emacs-diffs] scratch/octave-eldoc-fixes 1ad0826 1/2: Prevent > accept-process-output with quit inhibited in octave.el05. > > sent on 05.12.2018, 01:19 EET (I think that's the timezone). Hmm... looks like I already purged it. But based on the title, we could replace the `while-no-input` of eldoc with `while-no-input` inside octave.el's eldoc function, as in the patch below. Stefan diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el index c313ad1179..9fdeaa946c 100644 --- a/lisp/progmodes/octave.el +++ b/lisp/progmodes/octave.el @@ -1605,8 +1605,9 @@ octave-eldoc-cache (defun octave-eldoc-function-signatures (fn) (unless (equal fn (car octave-eldoc-cache)) - (inferior-octave-send-list-and-digest - (list (format "print_usage ('%s');\n" fn))) + (while-no-input + (inferior-octave-send-list-and-digest + (list (format "print_usage ('%s');\n" fn)))) (let (result) (dolist (line inferior-octave-output-list) ;; The help output has changed a few times in GNU Octave. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 10 17:59:16 2020 Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 22:59:17 +0000 Received: from localhost ([127.0.0.1]:39545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knUu4-0005vJ-OL for submit@debbugs.gnu.org; Thu, 10 Dec 2020 17:59:16 -0500 Received: from mail-il1-f172.google.com ([209.85.166.172]:42461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knUu3-0005v4-B5 for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 17:59:15 -0500 Received: by mail-il1-f172.google.com with SMTP id 2so6999323ilg.9 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 14:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=voBvpKxgoKJftLlDE18ySUhU9/ZzNg5jJVSsHw+/51w=; b=S95f77BPRhlDUVkKYJY0eXekJpyG3P3I0Fl33pLiQcR0C86ezbXKXLT5CSlx7CQ94s Llh9p97WIx2WYjGBtauPwJ51mV5C4Pc6TvVGkyT5EqYXvL+yKmlMpYyKUcmxYXtGBYdg 34mr8mgVCcXweCABGdlxjxxfCEO4SbP2T2J6Vm4mWlhCHKnzKu2a4plyjylHZuPE7JSm U7NKG2Soh/B6tMvPR3mfx5p8RWKDWsljHu3HTW/hHLXe/LLpC6xP0GizR6YiphZh6qIw xuzSG8mcIden7Z2+2HZwDXP7rB3A0DBbGLGit7gDYCyzVQ25twA0fmBl7HvfH5lETi6k efig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=voBvpKxgoKJftLlDE18ySUhU9/ZzNg5jJVSsHw+/51w=; b=ANu/CKEKY+IPrfg6WgvB3PHN3bOQ5y2EJ/vU2KtfEwkXThHL5wH0ltRrKBbMAeJtRR NKkRhRZ5Q04fNsJ9n748ykTKYVUhvO4uIw5Rno8ppNyglTgdeXy/zjJlY6cSRMmzSz/f ICiQ6xjNB7pcZsCug0oKalBVCem8QckhHKvXZB2VQiQjlsKiLyNxF+OkPTdpg/Tx0Nh2 2GGZG3wJGFHc0sMu8dex5j6cDE2zAP3JWAymAbjJIV/lzg2R46DIgS0xEmr3NuPeJxLq h7+HD3xNVQrnclDyo3pN8Zk6wVRMMTIevKp7SfW2B6JpKecj4ojkdvrr8j5S7CXvkmUi WuFQ== X-Gm-Message-State: AOAM532Db9n10e9A7eCGpjFEMRS5RqUXGqGgHEXmRxjeam8RwoV22upR uwVvJIvQ4HHJk/Z/9cNpNBMmkI9cTQm0mC8dUWA= X-Google-Smtp-Source: ABdhPJyey/hwKHZJ7EQcVRATzRv2jS1/iQFW+1iq/JueJvvyIIHFvVxYl9MTILgF7/QLVvdMfD4Bh/8esw+j8PBud04= X-Received: by 2002:a05:6e02:14ce:: with SMTP id o14mr11790472ilk.9.1607641149592; Thu, 10 Dec 2020 14:59:09 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <878sa51hwv.fsf@gmail.com> In-Reply-To: <878sa51hwv.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 10 Dec 2020 22:58:58 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Dec 10, 2020 at 9:16 PM Jo=C3=A3o T=C3=A1vora wrote: > > Maybe the maintainer of eldoc.el will prefer to undo this change, > > then ;-) ? > > Who's that? ;-) But OK, eldoc.el is now distributable independently so > we have good defense against this. Doh, I meant "against whatever third party breakage this causes". But in the meantime it seems you've already come up with a good fix for the Octave backend, which is in Emacs anyway. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 02:32:01 2020 Received: (at 45117) by debbugs.gnu.org; 11 Dec 2020 07:32:01 +0000 Received: from localhost ([127.0.0.1]:39831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kncuH-0003gl-3f for submit@debbugs.gnu.org; Fri, 11 Dec 2020 02:32:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kncuF-0003gX-GE for 45117@debbugs.gnu.org; Fri, 11 Dec 2020 02:31:59 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57832) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kncuA-00075E-85; Fri, 11 Dec 2020 02:31:54 -0500 Received: from [176.228.60.248] (port=2543 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kncu7-0000XM-SZ; Fri, 11 Dec 2020 02:31:52 -0500 Date: Fri, 11 Dec 2020 09:31:34 +0200 Message-Id: <83o8j03ijt.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 10 Dec 2020 15:43:16 -0500) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: joaotavora@gmail.com, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 45117@debbugs.gnu.org > Date: Thu, 10 Dec 2020 15:43:16 -0500 > > > process_send_string may send things in "bunches", I read in the > > docstring, but it will not (and should not) be interrupted. > > Indeed, I believe it should not be aborted in the middle by > `while-no-input` (it would be a bug, because the `process-send-string` > API doesn't offer any way to know what has been or hasn't been sent in > that case). If currently process-send-string isn't protected against while-no-input, then perhaps we should add such a protection? From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 09:31:52 2020 Received: (at 45117) by debbugs.gnu.org; 11 Dec 2020 14:31:53 +0000 Received: from localhost ([127.0.0.1]:40683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjSZ-0005fu-Tk for submit@debbugs.gnu.org; Fri, 11 Dec 2020 09:31:52 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30141) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjSW-0005Z4-Gx for 45117@debbugs.gnu.org; Fri, 11 Dec 2020 09:31:50 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3BBB3440F43; Fri, 11 Dec 2020 09:31:43 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 13D78440C66; Fri, 11 Dec 2020 09:31:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607697102; bh=gIKkK77kTSuHSlw3voC+aPGRNgZkXYYyLTFE6Vwb3kE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Ii9vo3exKKE+vD6bl9TAqqcFDU/AM67b7/h2UwtDng1HzDMt+JpR1VLfuIFWAH1xa yjZzIuSEVuNDi0A+5n3sdXgQ9K/48zvglTwNy2eGhqYkIrh0bMBwysIxqS3rZP/VFQ ZGKvWCqcyDOAnH4LyxocifPOrd9e7opWG7OVjW+UNs0VWlBFB5U87CqduRi/RXUmWV umEKwMxz/5dwcm22f07CUqJffxJlhp8JtNMKhCfk93O+oeXkPw668vseuw5Qpwc5Id nkAEGDoejMs4oVwI8xSAavO+g9robiAeuK1qpNr8CexgHGpjgtcEfBtWwXTvL0R56W oTbokQ725BsaQ== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D1B6F12014D; Fri, 11 Dec 2020 09:31:41 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> Date: Fri, 11 Dec 2020 09:31:41 -0500 In-Reply-To: <83o8j03ijt.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Dec 2020 09:31:34 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.075 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: joaotavora@gmail.com, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > If currently process-send-string isn't protected against > while-no-input, then perhaps we should add such a protection? Not just "perhaps" but "definitely". This said, I believe it already is "protected" so there's nothing we need to do (at least until we get a bug report showing I'm wrong). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 09:40:43 2020 Received: (at 45117) by debbugs.gnu.org; 11 Dec 2020 14:40:43 +0000 Received: from localhost ([127.0.0.1]:40702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjb8-0006Lg-Ls for submit@debbugs.gnu.org; Fri, 11 Dec 2020 09:40:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjb7-0006LS-3a for 45117@debbugs.gnu.org; Fri, 11 Dec 2020 09:40:41 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46977) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knjb1-0006kw-Lr; Fri, 11 Dec 2020 09:40:35 -0500 Received: from [176.228.60.248] (port=2786 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1knjb1-0007Js-0t; Fri, 11 Dec 2020 09:40:35 -0500 Date: Fri, 11 Dec 2020 16:40:18 +0200 Message-Id: <83pn3g1k4t.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 11 Dec 2020 09:31:41 -0500) Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: joaotavora@gmail.com, 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: joaotavora@gmail.com, 45117@debbugs.gnu.org > Date: Fri, 11 Dec 2020 09:31:41 -0500 > > > If currently process-send-string isn't protected against > > while-no-input, then perhaps we should add such a protection? > > Not just "perhaps" but "definitely". This said, I believe it already is > "protected" so there's nothing we need to do (at least until we get > a bug report showing I'm wrong). I thought this bug report was showing just that, doesn't it? From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 09:41:25 2020 Received: (at 45117) by debbugs.gnu.org; 11 Dec 2020 14:41:25 +0000 Received: from localhost ([127.0.0.1]:40707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjbp-0006N8-7H for submit@debbugs.gnu.org; Fri, 11 Dec 2020 09:41:25 -0500 Received: from mail-il1-f178.google.com ([209.85.166.178]:44736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjbm-0006Mu-Sq for 45117@debbugs.gnu.org; Fri, 11 Dec 2020 09:41:24 -0500 Received: by mail-il1-f178.google.com with SMTP id r17so8959855ilo.11 for <45117@debbugs.gnu.org>; Fri, 11 Dec 2020 06:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SpwUFyxn8zzZ8v7q0gT6LyI78rAYmkfvkCcGvTt7aeA=; b=PtFLChQnkzSdXlgMiWf9Efa4DA9G2b6hlIvPi0yK9WjsB1sMi+YeL0n6ghN8eSXSNv K+bKqhgh05r/AAyNVy3mn6GxAZQA8RJjByxraO9aqwQZEYQuGyLB5lDLS6gQYcAzbAee pdEzFgqSny9ZSQEyCVl5C0YjKCmt30KfniZ3m+/jGmiQxioyhA2gjjz50FGUyREn5a1x kAnAnXLmGZAVnTrkKQrgQVmg0E+yEJobwHzOBy6ZM1TlC9GHl+sEUivqeKbq+8nHZWT0 wMIrQEimNMpwrDnu19aQ1L/d25zpkyQhpmk8QSaWFgGT38jWKjL4QCuLM+sKQ7j19H6R t7FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SpwUFyxn8zzZ8v7q0gT6LyI78rAYmkfvkCcGvTt7aeA=; b=WsWxIs1LcbEslAPJBaG4R6QSY5FWl3ighNnc+QnOt6dd4VVxav+RBIhFqu7P7ZAoPq +mCjcOnQQQUzE9UmDetwojBtzmKRsoSUmpPoUEi7buQfkJZfmEurnQGcqzIJXPlRfvg0 AN5X7LDkJCTM78HUGXs3gpTtXXLHJsYHG9UgUvzfaE/R79m/8/cU+3ZYhnPtszy1xL9P MvT1bj5AJrv5Ij/VAoLbrfBi4h5qJIqLqtIfWjAnreN2ISo1Aia5kN3NSFIU3kK6f5bW tEHxEFWSiIXTTeSQXXeb5dqFPxKxhy8o9RF4eLa1/gc720kL/Q1jM1u3yfYgFIFwLsRi a69Q== X-Gm-Message-State: AOAM533sMB9x59/QN0VZrID844ylrYl0f6ZiGu4PplBjX5Z/Q28BDO4Y XHZbqwMGy9hhvtU1nVDxCMTIt71KD7ucPGR5GAw= X-Google-Smtp-Source: ABdhPJwjKg0KlHiq4B74r/F7WYfIUIyjSjUcs9Xx5EwYsIkmo6zrdOT65rAhUieNkGFvyB8zkS9hXRAp6pmCfo2KVhw= X-Received: by 2002:a05:6e02:14ce:: with SMTP id o14mr16619360ilk.9.1607697677205; Fri, 11 Dec 2020 06:41:17 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 11 Dec 2020 14:41:05 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Dec 11, 2020 at 2:31 PM Stefan Monnier w= rote: > > > If currently process-send-string isn't protected against > > while-no-input, then perhaps we should add such a protection? > > Not just "perhaps" but "definitely". This said, I believe it already is > "protected" so there's nothing we need to do (at least until we get > a bug report showing I'm wrong). In this bug report, I did observe a non-local exit from process-send-string once or twice, though it was rare. (look up). My theory is that for strings that go in bunches, when there's some output to accept, things can come in that cause the quit. But I didn't investigate. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 09:43:21 2020 Received: (at 45117) by debbugs.gnu.org; 11 Dec 2020 14:43:21 +0000 Received: from localhost ([127.0.0.1]:40720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjdh-0006Qz-0K for submit@debbugs.gnu.org; Fri, 11 Dec 2020 09:43:21 -0500 Received: from mail-io1-f50.google.com ([209.85.166.50]:38640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjdf-0006Qm-BE for 45117@debbugs.gnu.org; Fri, 11 Dec 2020 09:43:19 -0500 Received: by mail-io1-f50.google.com with SMTP id y5so9686466iow.5 for <45117@debbugs.gnu.org>; Fri, 11 Dec 2020 06:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8seY8RtFu2hIyQ7dBadTzgKu5QLXJD/3GeriqzO31aw=; b=E1QpAQueDHHmxPOPzl6dnE4sQ2cKLRen4e7R55D7piWi29ZrwKmFqicXvgO0jaJ3uw f1HS92HnR+jsUjeLMI5LqImyEbXo0JUF/XFCM+fwY39g07b1wieOKNVahaxSsNPXXxqg nacrSysuV/M1WCmi94EZP/rYU33A9BJwpwzWYZ9VV1eYnjfXSXDrl8Qz973JxsNTqL3i f271SMl2cXFkKSTotM4ThcvMaiRROM5YGu4VZt7gnmC/Sv25YM0t0AIv/ibKq4LN1rTQ i6DtcVQ+V+y+10GuIjZwwh5tlKATt65gXJtwcQuQs0nMdoPf2TT8+JQvLDItrz5vExAL JPBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8seY8RtFu2hIyQ7dBadTzgKu5QLXJD/3GeriqzO31aw=; b=FOG8ATa7Wm4kQQWl5G7S8fNYStKFDmv4ZVEBr4HkQQ/5buX4slrg6iSPVqEqfU62/f Gj3Vr3dODvQK9F7I/C2nk606kjtLidUDqmlQArFXihrnHZsL1Mk+pxFKC2anzK/4PvKp sA8isZEZwHwHSfWk7nYVZlS0Os7iBlbOd/Er58EUMNGr8eUE7gazbBdltMmJwyr8N5Ph ra5Bz3UsnIgJLEbMq1kg+eZatZK+rxHLHsmcHHExGmjPeGPH81bVXR5oOMuCgKP7NgZW ejKrjbH7F8b95pgN33p6RCqKRhB1+baQY50tSfU5F3kf/vn83lYvLC6q9wOpQ1ZOZzlV 9pCw== X-Gm-Message-State: AOAM530vJKjK6qtMIsfR/OUw9cHLo/PuX361xYhj3mTXY6Oe+EUzPTrJ lbD3fHbwHmTDNY+Mv8fXJmU20iiI2+rcyvsIdGt8qG2s X-Google-Smtp-Source: ABdhPJypGwmzhW5u2vH0hsQTcfeSPO1yMuTCuMpie6HnbSYpniNw8wEkGlThKJ6N00+1nHa4Dh1V9PQuFVPoMRe9pYA= X-Received: by 2002:a05:6602:314b:: with SMTP id m11mr15547909ioy.165.1607697793750; Fri, 11 Dec 2020 06:43:13 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> <83pn3g1k4t.fsf@gnu.org> In-Reply-To: <83pn3g1k4t.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 11 Dec 2020 14:43:02 +0000 Message-ID: Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117 Cc: Stefan Monnier , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In Fri, Dec 11, 2020 at 2:40 PM Eli Zaretskii wrote: > > > From: Stefan Monnier > > Cc: joaotavora@gmail.com, 45117@debbugs.gnu.org > > Date: Fri, 11 Dec 2020 09:31:41 -0500 > > > > > If currently process-send-string isn't protected against > > > while-no-input, then perhaps we should add such a protection? > > > > Not just "perhaps" but "definitely". This said, I believe it already i= s > > "protected" so there's nothing we need to do (at least until we get > > a bug report showing I'm wrong). > > I thought this bug report was showing just that, doesn't it? Yes, the title is just that. However, after digging down the analysis I found that only a small fraction of the unexpected quits I was getting actually happened in process-send-string. So the title is a bit exaggerated, but it does happen. I think for larger strings, but not sure. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 09:50:53 2020 Received: (at 45117) by debbugs.gnu.org; 11 Dec 2020 14:50:53 +0000 Received: from localhost ([127.0.0.1]:40734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjkz-0006dD-D0 for submit@debbugs.gnu.org; Fri, 11 Dec 2020 09:50:53 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knjkv-0006cy-RE for 45117@debbugs.gnu.org; Fri, 11 Dec 2020 09:50:52 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3B0188070D; Fri, 11 Dec 2020 09:50:44 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EFA048005E; Fri, 11 Dec 2020 09:50:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607698242; bh=ikCqWBbWTnhhWjcaZwRZiVrab9TzyyrRpFZ5dSl8T18=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OFxobc6FMAeHNMdzjC0xHzbIlXQJHtqryIgGj4oMToOqYxEgQwYSxUV8IVe9Ra6SR Jqhk1+2KfREpJZMOgEs9feisT/zZ5+yKKf1U28J/zE6AVzZO1UsDvOTtAgbqbbV20L SYW3HPfPseG0NHadqADhXBdv51zTI7SdI68YI+0EYkfl2kS3MYq9Uq8khXVgpYP24R nnj45L4zvk/tezENUEru/QSYsvPupVkqAupCwT+9Hrlq7mDnQfPysjuFanA7c+BzAp I0PywsbBOq+y0+W4upPwpyJDhiiA65u1kO1tJSHehsCcA8Vl4J/3jndrHzR53/VcfE a5a6gFC6IHTyg== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BBE24120246; Fri, 11 Dec 2020 09:50:42 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> Date: Fri, 11 Dec 2020 09:50:41 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 11 Dec 2020 14:41:05 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.061 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117 Cc: Eli Zaretskii , 45117@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > In this bug report, I did observe a non-local exit from > process-send-string once or twice, though it was rare. > (look up). My theory is that for strings that go in bunches, > when there's some output to accept, things can > come in that cause the quit. But I didn't investigate. Hmm... indeed it seems I was completely confused. `process-send-string` is even a context-switch point, so it can definitely do a non-local exit for all kinds of reasons (quit and while-no-input being just some of the possibilities). IOW, better disregard what I said in this thread, because I was talking about things I don't know. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 18:19:56 2020 Received: (at 45117-done) by debbugs.gnu.org; 13 Dec 2020 23:19:56 +0000 Received: from localhost ([127.0.0.1]:50714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koaei-0003hi-5o for submit@debbugs.gnu.org; Sun, 13 Dec 2020 18:19:56 -0500 Received: from mail-il1-f174.google.com ([209.85.166.174]:39160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koaeg-0003hV-MP for 45117-done@debbugs.gnu.org; Sun, 13 Dec 2020 18:19:54 -0500 Received: by mail-il1-f174.google.com with SMTP id q1so14205374ilt.6 for <45117-done@debbugs.gnu.org>; Sun, 13 Dec 2020 15:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=TNOuoujWJBSiBrE1kLr5ue2Q0pSraMlizts1KPfz5ic=; b=SxmPulBcWAkCkFxlO2PLJ+L/sos49qdBooiaMoVnSRz4VNGlsuzofF8DPeg58Sr7bz KK3fT4kvUGyuErzxSKOaBfg1G44x5tYppKL7b1O2SUEJl89OjZEEP9klcmHhHIE0Nsen jN3rVSxwxYEh0vlTAE0i7+wz6qTUtUVQxO7PrAL/rPvbSaSIJGEZZMbpqMIaACNXtqLY r+2zlNUk6CzXIL2S+vboC/x+QDN+/pG6cpqfJ0Jxc5L2q21pjE41HpYcCbf5xvtU1i3K lEvmHMYL/C7ect/ZHIXiEvSIL1vPvmQbqWZhVioo18Sksvqf4DseFO+eqQZjL1+yL2R0 vfOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TNOuoujWJBSiBrE1kLr5ue2Q0pSraMlizts1KPfz5ic=; b=nLbcopmvZjNdyeKRo7CWFIzC/uqEeM04hbKMXypHahAMsAI0hP94YTfDFr4AsIfmuo xSEMKJmg+Ji5hJX2dMdIg0Lb7nrVdc1teLM5fcbCOcld6EkIwco3s5+oafkVzwONSqeO 4MpVuoC1inJ1+VseobzVRz9ytn3UBibn1fm35olIj/l35eR+6DZvKPJqV/RL08A50M6P DHZMjSCOZ+0FuRH+cHd4os+TbRuM9JVJulhWaeHFjWvKlGd+nM7MRA5iVGt/DVQvQRfC pLTQ6auI8bn1kBxgKVcaSu+yAQz/7u8WLXHHy6V1GMsC4eS/NMQUdfQHQqLPEWzMsVdC TR8w== X-Gm-Message-State: AOAM533HWQBCCzYjhQJOl1vbiWe7MmQ104NaBAq845W3+z3EnZ6HWqMI QtgeinDLeVs+vJhSo9m20VR95Zcg0PGcXo6+RYw= X-Google-Smtp-Source: ABdhPJyCy2kLuDodTkdOL/bWBPMcoF7JTjVAzDX+3CyN7l/R6M+wCc6RT3g5fnYaQreSWg6Yaf9weroruiww1o2Ajm8= X-Received: by 2002:a92:c682:: with SMTP id o2mr31134809ilg.97.1607901588913; Sun, 13 Dec 2020 15:19:48 -0800 (PST) MIME-Version: 1.0 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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 13 Dec 2020 23:19:37 +0000 Message-ID: Subject: Re: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer To: Stefan Monnier , 45117-done@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 45117-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pushed the fix we agreed to (eldoc + octave). Closing. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 13 19:35:30 2020 Received: (at 45117-done) by debbugs.gnu.org; 14 Dec 2020 00:35:30 +0000 Received: from localhost ([127.0.0.1]:50755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kobpq-0007et-An for submit@debbugs.gnu.org; Sun, 13 Dec 2020 19:35:30 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21027) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kobpo-0007eg-RR for 45117-done@debbugs.gnu.org; Sun, 13 Dec 2020 19:35:29 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 888018079B; Sun, 13 Dec 2020 19:35:23 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A22A28056D; Sun, 13 Dec 2020 19:35:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607906121; bh=6CiUHz02/K7F9D7iECL8XD30FJoBNsE46q4GMjyUYVo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pCoDM45P1B8ify+LfJY+Q70zMOwBY/ykOFZC2IdvaK81jTppM8gH4HIaQR/buzgCA ulVmhjOHGtLVB1PHCjeVuhlrOUugsmJmJP5Q5ZyW+wp0rBN8EGIhTRX04Pqq9LItCs DxrIXKAdC4zKEn/NDyzrU3Vgh+X+OCq84lNxhDxBl08sBmWKcc7U/gPTFW9HriVZUo v3g3M5uLxZp9342OKvP8TXxnYhw/uWqCUGp6KC395Dct/A06q1ScrOv3YMnJfL2W/n GB3ITvreu2SsUE5xoDkST27AEvTTm1h1/aGKVytsNv9Fwwc/fjCmOv+tlBKPkrQPYB LzQVdX3Z7tyVg== Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 614F21203D8; Sun, 13 Dec 2020 19:35:21 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer Message-ID: References: <87h7ow4j4o.fsf@gmail.com> <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> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.fsf@gmail.com> <83o8j03ijt.fsf@gnu.org> Date: Sun, 13 Dec 2020 19:35:20 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Sun, 13 Dec 2020 23:19:37 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.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 AWL -0.064 Adjusted score from AWL reputation of From: address 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: -2.3 (--) X-Debbugs-Envelope-To: 45117-done Cc: 45117-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Pushed the fix we agreed to (eldoc + octave). Closing. Thanks. FWIW, after thinking about it some more, I think the `while-no-input` in Octave is also suffering from the kind of race conditions discussed here. Stefan From unknown Sat Jun 21 10:22:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 11 Jan 2021 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator