From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help,gmane.emacs.devel Subject: Re: Temporarily disable `timer-event-handler' Date: Mon, 03 Feb 2020 09:01:47 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="20793"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: help-gnu-emacs@gnu.org, emacs-devel@gnu.org To: Alexander Shukaev Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 03 15:02:42 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iycJF-0005Gz-Gq for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 03 Feb 2020 15:02:41 +0100 Original-Received: from localhost ([::1]:41292 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iycJE-0001p3-Hi for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 03 Feb 2020 09:02:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57932) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iycIc-0001kk-G8 for help-gnu-emacs@gnu.org; Mon, 03 Feb 2020 09:02:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iycIb-0005zb-5V for help-gnu-emacs@gnu.org; Mon, 03 Feb 2020 09:02:02 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30255) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iycIX-0005or-RF; Mon, 03 Feb 2020 09:01:58 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4AF2410078F; Mon, 3 Feb 2020 09:01:56 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25DC110031F; Mon, 3 Feb 2020 09:01:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1580738514; bh=VKVDYBzLL77hzX5lxo0z2tczy68UiOWYI9jUI0P5p00=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z0QjWYnEi5oriamzmOMluSfAvcmQMbCk9U3BI0eHanr4tZRvXINGwLWtzuZ7e6FTb aBMXUKmBNvkPk5O9ZTXJLSMoaW6TdzX1f3ojzBCERNaQTEK87a2YYN/vtGACLy5n8z itnB16+Q6LZJP1T7i3DpW0w/7wfhqwKeu/iQs7omQb8rE9gBb3KcGRrVF1Qx3o4EMK AZeIUGyYWbOwdTjL343oKt90SY+D7wwXInUyKiA4BXdZJVULC5f3X0tOdb+Fgu7md0 KxbCdnSXYxjVJIghHcWr1kjRO08Fo6t8Yc7jp0JwrMB8J/5uGbEvjMIJ8Rw8ggPsh3 TMvwiktdtuWdw== Original-Received: from pastel (unknown [216.154.34.88]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D39D41201F4; Mon, 3 Feb 2020 09:01:53 -0500 (EST) In-Reply-To: (Alexander Shukaev's message of "Mon, 3 Feb 2020 00:25:00 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:122334 gmane.emacs.devel:244828 Archived-At: > - Event `A' scheduled to run ASAP. > - Event `B' scheduled to run ASAP. > - The expectation is that `B' strictly runs after `A' finishes execution. There's the rub: currently, there's no such guarantee. The only "guarantee" we provide is that the processing of event A will start before the processing of event B. [ Note: "event" here can be a timer firing or a process output. ] > - Well, if `A' calls `message', then according to the above, `A' could > indirectly run `timer-event-handler' (nested) which, as a result, will > run `B' now essentially somewhere in the middle of `A'. If A and B are unrelated, there's no problem. If A and B are related, there could indeed be a problem. And notice that event B could even have been created by the processing of A. But there can also be cases where A does want/need B to be processed before A ends. [ Another related situation is when A is a repeated event and a second A fires before the first one is done processing. ] > - Clearly, unless taken care of, this may result in side effects and nasty > bugs, which are difficult to track down. Yup. > Another possible side effect can be related to e.g. `let'-binding, when > during an execution of some function some `let'-binding is performed, > but `redisplay' is being triggered and some timer event occurs under that > `let'-binding, which unfortunately affects it in a buggy unexpected way. > Also difficult to understand and hunt down. Oh yes, dynamically-bound vars can make that even more interesting. Process-filters and timer events (and jit-lock, and the debugger) should ideally be run in their own thread (and hence not affected by dynamic-bindings in the interrupted threads). Existing code does occasionally depend on the current behavior, tho (e.g. in `jit-lock-deferred-fontify` we bind `jit-lock-defer-timer` around a call to `redisplay`), so fixing this is not completely trivial. > Now, first of all, do I understand correctly that the recommended way to > temporarily prevent timer events from happening is to `let'-bind both > `timer-list' and `timer-idle-list' (similar to how TRAMP does it e.g. in > `tramp-accept-process-output')? How about a stock macro for this? The recommended way is to find a solution that doesn't involve preventing timers from firing, so a stack macro for it doesn't sound right (e.g. in the case of Tramp, the discussion in bug#29735 seems to indicate that Michael agrees that disabling timers isn't "right" but it's just what he's using so far because he wasn't able to track down the bug in the "right" version of the code). > I suspect that most users are not aware of this complicated design. I don't think the design is complicated. It's the resulting behavior that is (arguably because the design was too naive). > Finally, what's the motivation behind this design? This looks fragile and > error-prone to run some arbitrary code in the middle of execution of another > code without separating their "stacks" (environment scopes), It's a direct consequence of the implementation, rather than the result of design, AFAICT. > Why not only allow timer events to run at "safer" points of execution? > E.g. no nested timer events, That's probably a good idea, yes. Probably worth giving it a try so if/what breaks. > never in `redisplay', Agreed. Feel free to consider it as a bug and hence report it when it happens. Stefan