From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: master 8c81818673a 6/7: Tune volatile in read_char Date: Mon, 19 Aug 2024 20:08:26 +0000 Message-ID: <87wmkcb7ig.fsf@protonmail.com> References: <172386820621.30556.15409337288904485218@vcs2.savannah.gnu.org> <8634n0y2th.fsf@gnu.org> <87plq4cyuj.fsf@protonmail.com> <861q2ky0tg.fsf@gnu.org> <87le0scxig.fsf@protonmail.com> <86y14swksj.fsf@gnu.org> <871q2kcp0a.fsf@protonmail.com> <86r0akwbuk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3971"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 20 04:20:27 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sgETy-0000rB-NG for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Aug 2024 04:20:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sgET0-0006uG-EZ; Mon, 19 Aug 2024 22:19:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sg8g8-0000oT-Gb for emacs-devel@gnu.org; Mon, 19 Aug 2024 16:08:36 -0400 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sg8g6-0004dZ-J6; Mon, 19 Aug 2024 16:08:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724098110; x=1724357310; bh=KQoDEzvyckvSICl8f0jwaHayUSRPTO63AHJuZtDU3LY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=PTtKn4pH1c0YPx3MKIt6six4PIgO5/9c8JrCJ81QfAtnOlwLiyj1Vt4u86dfRWgNN SbWGEaiOV14pcKRmMIOXLfHtxZJJzQ0zZXDtuU4uSBk4WnurTkJ1PaWg85IAdMNpIz Zoe8bQi9RZbyCsAkcSTYZyJf5jYptbTiUF8Vi7gZh66p1j8fqHjH0RZqr3aATpHUNz dh9dvqjW7LdJUk5CqAItuaNqproWRS6t75p1DmuFpLOF/wQAbpDP1R6Qo95gkui96X ubKNk3UeyHJgshORnq0gJjG620JPoICPTTdPorZcgUeOuK+mR2FwZ/Rw0194edlHpf I+7ZsgISgmr/g== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b093f3b2bf563dff187015f3e8c3527bcbcddefb Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 19 Aug 2024 22:19:24 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322951 Archived-At: "Paul Eggert" writes: > On 2024-08-19 12:29, Pip Cet wrote: >> now we reset the quit counter to the value it had when we >> registered the handler, which might reduce it, and thus lead to missed >> quits (though I haven't found a bytecode object that causes that bug >> yet) > > I don't see how that could lead to missed quits. Can you explain? (Are > you thinking of dealing with corrupted bytecode objects? But I don't see > it even then.) Well, before the patch, the logic was: quit_counter always increases, once per backward jump, except when it becomes 0, and then we quit. Now, I don't understand the logic, but it's complicated: * quit_counter usually increases * but sometimes, it's reset to a lower value, when we hit a condition case handler * there's no guarantee, or not a strong as there once was, that we will call maybe_quit * there certainly is no guarantee that we will call it once per 255 backward jumps > quit_counter is merely a heuristic: it merely needs to increase if the > current bytecode object loops forever. If I understand things correctly > this increase should happen (albeit perhaps more slowly) regardless of > whether your proposed patch is applied, which means the patch shouldn't > be needed. I believe you're right and the "once per 255 backward jumps" simply becomes "once per 254 * 255 backward jumps", for compiler-generated bytecode. In my defense, I did say it was subtle :-) (The rest of this email may not be interesting, feel free to skip it: A highly contrived example here, which results in maybe_quit() being called from exec_bytecode() with the old code, but no such call with the new code. Consider: (disassemble #[65535 "\210\3011\0\0\202\013\0\302\211\241\202\010\000" [argument wrong-type-argument 0 t] 65536]) which results in: 0:1=09discard 1=09constant wrong-type-argument 2=09pushconditioncase 1 5=09goto=09 3 8:2=09constant 0 9=09dup 10=09setcdr 11:3=09goto=09 2 There's a backward jump, so this code should call quit, but now it doesn't. Of course, one can come up with similar examples without a backward jump, which loop unquittably even in emacs-30, so all this is academic at best. I'm pretty sure behavior also changed for self-modifying bytecode objects, but that would be cheating.) Pip