From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alexander Shukaev Newsgroups: gmane.emacs.devel,gmane.emacs.help Subject: Temporarily disable `timer-event-handler' Date: Mon, 3 Feb 2020 00:25:00 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="38976"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 03 00:25:48 2020 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 1iyOce-000A2s-0I for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Feb 2020 00:25:48 +0100 Original-Received: from localhost ([::1]:60452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iyOcd-0000G7-1m for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Feb 2020 18:25:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50084) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iyObz-00086p-1O for emacs-devel@gnu.org; Sun, 02 Feb 2020 18:25:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iyObx-0003PI-PT for emacs-devel@gnu.org; Sun, 02 Feb 2020 18:25:06 -0500 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:59029) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iyObx-0003KJ-JL; Sun, 02 Feb 2020 18:25:05 -0500 X-Originating-IP: 88.68.139.217 Original-Received: from [192.168.3.109] (dslb-088-068-139-217.088.068.pools.vodafone-ip.de [88.68.139.217]) (Authenticated sender: forum@alexander.shukaev.name) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 380A340003; Sun, 2 Feb 2020 23:25:00 +0000 (UTC) Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.183.194 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:244822 gmane.emacs.help:122332 Archived-At: Hi, I've recently discovered the dark side of Emacs: that timer events run by `timer-event-handler' can be triggered either at `top-level' or at `recursive-edit' or as part of `sit-for' (see `input-pending-p') or `accept-process-output' or `message' (which triggers `redisplay' and subsequently C function `redisplay_internal' that invokes Lisp interpreter machine yet again and hence potentially `timer-event-handler') or maybe even more. With such plethora of possibilities for `timer-event-handler' to run especially in a nested manner one could even observe an interesting peculiarity: - Event `A' scheduled to run ASAP. - Event `B' scheduled to run ASAP. - The expectation is that `B' strictly runs after `A' finishes execution. - 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'. - Clearly, unless taken care of, this may result in side effects and nasty bugs, which are difficult to track down. 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. 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? Secondly, does the above explanation, pitfall examples, and recipes to temporarily disable timer events in the middle of Lisp execution appear anywhere in the documentation? I suspect that most users are not aware of this complicated design. 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), and even then their global side effects might interfere. Why not only allow timer events to run at "safer" points of execution? E.g. no nested timer events, only at `top-level', never in `redisplay', also allowed in-between some blessed hooks executions?