From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#29735: 27.0.50; It must be possible to suspend all timers Date: Tue, 19 Dec 2017 19:47:08 +0100 Message-ID: <87y3lya72r.fsf@gmx.de> References: <878te28zas.fsf@gmx.de> <837etmskvi.fsf@gnu.org> <871sjt3eoe.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1513709176 28120 195.159.176.226 (19 Dec 2017 18:46:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Dec 2017 18:46:16 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: 29735@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 19 19:46:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRMu3-0006vR-Q2 for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Dec 2017 19:46:12 +0100 Original-Received: from localhost ([::1]:59714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eRMw2-0004U4-5h for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Dec 2017 13:48:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eRMvu-0004TP-Ka for bug-gnu-emacs@gnu.org; Tue, 19 Dec 2017 13:48:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eRMvr-0002Yi-8h for bug-gnu-emacs@gnu.org; Tue, 19 Dec 2017 13:48:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33953) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eRMvr-0002YZ-3j for bug-gnu-emacs@gnu.org; Tue, 19 Dec 2017 13:48:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eRMvq-0003uh-Tc for bug-gnu-emacs@gnu.org; Tue, 19 Dec 2017 13:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Dec 2017 18:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29735 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29735-submit@debbugs.gnu.org id=B29735.151370925514989 (code B ref 29735); Tue, 19 Dec 2017 18:48:02 +0000 Original-Received: (at 29735) by debbugs.gnu.org; 19 Dec 2017 18:47:35 +0000 Original-Received: from localhost ([127.0.0.1]:42630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRMvP-0003th-IF for submit@debbugs.gnu.org; Tue, 19 Dec 2017 13:47:35 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:64303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRMvN-0003tT-Pg for 29735@debbugs.gnu.org; Tue, 19 Dec 2017 13:47:34 -0500 Original-Received: from detlef.gmx.de ([212.86.37.160]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MI5rO-1eQntH0DzK-003rEz; Tue, 19 Dec 2017 19:47:21 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 19 Dec 2017 10:58:40 -0500") X-Provags-ID: V03:K0:ncKMN4sEyXPTbE9rt+z0GOuULeeP/jTDtALPn0QFx8EVIwllcLB SrQVJR4ulzDeok3zPnMmDwBVWo3CbybgGA0DEX+IOH5uY3VbPpGAYncbM2gjFwmei6D4c22 XaZZAuJ9IGaxEwehJ9zH7ZOjP5RolDvI92W5VgP5EfK7iQ6TYgeLsa4ClV0YeBy/XaMRxBN HYmJfNy+iyB5fGtU+O4VA== X-UI-Out-Filterresults: notjunk:1;V01:K0:mnz8ouRCAeE=:DDs/hswtkOJQTRlr1DTEX+ VHHWRjaUkei95M0cKeGs1nqSCKMQSXIkqYOcVDtyHkM4vxWx6SCAWfdcYJhnJAOFk37w7uYnk K44xR4/0By9M9cOwPcIkH2xyeVgMwFdip9jJtIme3AnKntlyR5i2SJMa58IL2Igd5qczLExLR Hc9OfV/j+272C8S+fsL0NWULVKkp11chBAnJu/7ux8zW85CyPKuIBRVN45XJXxMPp5xMTF8+Y ImxptM7BHDXS0xMGHHDlkL7O0CiW1Ew7Vr7ACd0OOQXtsT98sYB4bWnFJ/XQw9oPraYQCcaXR BO1QXUBqDbIRaq5oFCfG+tWFIBYOnLw6hfd+XlOT9vIh8IjqVfBn91pQUSH24oCqT5WREWcPW 8yoOL77z5bvNhrQeAkp9hpXXPt43tsTl7QzrQjy/6imbeHh2WCJe/UGnY6nxCmqFBlW7gIDW2 XmukHhaPutoJg2pNrL6LHAsUEwsXCILH5eY8cQVfnFkXzny4OYCo94Z0CxEdFq52RoyOmFgMr MTbFZVcEALlx7wIqHiS5Nc+xxwPbLqfZ1mRfHgr491bnRU/C3Se4crGHKln9R5sSwwobI8qiG 7/1X4LWfrisQjovTlfbvHtCk/2QeqW2PGBnjo0NuKbjMZjH/X0HeVtRkyrCRQajpMZ07ZJfE+ eNB4RimE6wqdN8JME4wVOlew6YS1saUcvpoxaJnV5GrrRcMCAWiUlvZS4t0zt/cwp3h3fSx8O YpMgx01hRya9i/2bC4Wc4NwVg9nuO0uK4mpZqS427KAgYP8El2xbo3Kb6gW0cJVrKhLGwLmN X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:141261 Archived-At: Stefan Monnier writes: Hi Stefan, >> If during that time a timer starts, which wants to apply a regular file >> operation (let's say `file-attributes'), the corresponding commands are >> sent to the process related to the just started asynchronous process, >> instead to the working horse *tramp/method host*. This fails, of >> course. Therefore, the start of timers between the both code samples >> must be suppressed. > > Hmm... but IIUC the same problem shows up if some random process-filter > or process-sentinel uses, say, file-attributes on that same host, right? > So it's not specific to timers? In theory, yes. But I haven't seen it yet. During the initialization process of Tramp's asynchronous processes, in `tramp-sh-handle-start-file-process', no process-sentinel or process-filter shall run. Tramp itself tries to avoid this, by calling (accept-process-output proc timeout nil 0) See `tramp-accept-process-output'. The other situations process output could arrive are `sit-for' and `sleep-for'. I'm not aware that these functions are called inside the process initialization of `tramp-sh-handle-start-file-process'. > From the description you give, I understand that: > - start-file-process causes the creation of a new underlying ssh process > (that makes sense). yes > - so from then on, we have 2 (or more) ssh processes on the same host > and the issue is to know which process to use when. yes > So the problem is to somehow get the "context" of a given call to Tramp, > so as to know which process to use. > Do I understand correctly? yes > Currently you store which process to use as a "connection-property" > (and it defaults to the "main" process), so basically the "context" is > store in a kind of global variable. yes > Would it make sense to try and pass that "context" information as > additional arguments instead? Or via dynamically-coped variable? > > E.g. any call to file-attributes (or any other file-name-operation) > should always use the main process, right? So the mapping from > connection->process could be stored in a dynamically-scoped var, and > tramp-file-name-handler could let-bind this var to nil? That's exactly what I've tried prior the current implementation. `tramp-file-name-handler' is the main door all file name handler operations must pass. Inside this, I've stored the setting of the process connection-property somewhere, and I've set it to the "main process". After the respective handler function returned, I've restored the process connection property to its saved value. Unfortunately, this is not sufficient. I've still seen errors in `tramp-test41-asynchronous-requests' from time to time. And as I said already, it is almost impossible to debug this. It happens rarely only, and debugging changes time conditions. > Stefan Best regards, Michael.