From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Tramp and timers Date: Sun, 13 Dec 2020 12:43:17 -0500 Message-ID: References: <87ft4c5lfu.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22794"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 13 18:49:01 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 1koVUS-0005m8-KI for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Dec 2020 18:49:00 +0100 Original-Received: from localhost ([::1]:35998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koVUR-00084o-KO for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Dec 2020 12:48:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVP6-0001pd-49 for emacs-devel@gnu.org; Sun, 13 Dec 2020 12:43:28 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8229) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVP1-0003qB-Jn for emacs-devel@gnu.org; Sun, 13 Dec 2020 12:43:26 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 51558100317; Sun, 13 Dec 2020 12:43:22 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25C401002B8; Sun, 13 Dec 2020 12:43:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607881399; bh=7lewU8n+yt/KrQ331O5eES0PLhDtDYgdD1QITpyX7Ds=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=oU/fHCg599e608PiKi2c5eDdvakwfaQs/qeKKknVlxDtK1CTgc5CLXbMLHXj2qpm4 G7jKiKoDrTh3BRpTJVZfECfMbw5b9J6DS1eWpuNgkQ1MStF59XArzQZJBKPBygSBqw 38wLUk/zCAHpNG9UV+rRF7upEWA+XaEWPTAIbeQJPLtrwI4NqjCY3GM5yxq/j1d/4v MnLcRaSHCfbFMgs7PtNazzEW1yO5DkONvgz8TaEZRzbxoZhsFjC/F5FC0EWLxkmKlV MWqSkfI3IiXSYjNTJuq7aWP7dvEziCl/DK8WsiDL7na/Eeb9wPQXx5Q73p2jO6jK5M X4PCZvhk2Z/mA== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D4869120392; Sun, 13 Dec 2020 12:43:18 -0500 (EST) In-Reply-To: <87ft4c5lfu.fsf@gmx.de> (Michael Albinus's message of "Fri, 11 Dec 2020 17:58:29 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:260768 Archived-At: > Tramp is plagued since ever with timers, which run while Tramp is > performing accept-process-output. If such a timer runs an operation > which includes also a remote file operation, it ruins Tramp's current > process handling. See the discussion at > > for a recent problem. Here's my take on it (I'm not familiar enough with the code to be sure it's workable, so it's more like a backseat driver's design, so feel free to ignore): I think it should be OK for the timer to access a Tramp file on host A while we're in the middle of a Tramp access to a file on host B. So the interference should be detected "per connection" rather than globally. Every connection should have a lock. Whenever the connection is "in use", we take the lock. This is also useful in the case of the use of threads. When we try to take the lock and it's already taken by another thread, we should just wait (or rather, the lock should do that for us), but if it's already taken by the current thread then we should instead signal an error like `tramp-recursive-access`. Timers should arguably each run in their own thread. Of course, they (currently) don't, but if a timer function wants to use Tramp files, then it should start by delegating its job to a thread (we should probably have a standard function like `run-with-timer-concurrent` which calls the timer function in a separate thread). If they don't, then the risk getting `tramp-recursive-access`. IIUC your proposal is quite similar to what I describe, Stefan