From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: Introducing thread-safe Tramp Date: Sun, 29 Jul 2018 11:54:11 +0200 Message-ID: <87sh42gyf0.fsf@gmx.de> References: <8736wa9c5s.fsf@gmx.de> <3e63b230-6cc1-f517-da71-57b892e14e30@yandex.ru> <87wotfhdn2.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1532857973 23433 195.159.176.226 (29 Jul 2018 09:52:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2018 09:52:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 29 11:52:49 2018 Return-path: Envelope-to: ged-emacs-devel@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 1fjiNd-0005z3-1q for ged-emacs-devel@m.gmane.org; Sun, 29 Jul 2018 11:52:49 +0200 Original-Received: from localhost ([::1]:47699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fjiPi-0003V3-2P for ged-emacs-devel@m.gmane.org; Sun, 29 Jul 2018 05:54:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fjiP3-0003Uw-NH for emacs-devel@gnu.org; Sun, 29 Jul 2018 05:54:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fjiP0-00086z-LF for emacs-devel@gnu.org; Sun, 29 Jul 2018 05:54:17 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:39657) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fjiP0-00086l-B2 for emacs-devel@gnu.org; Sun, 29 Jul 2018 05:54:14 -0400 Original-Received: from detlef.gmx.de ([212.86.51.86]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lmr1w-1gB50S3IxY-00h3xi; Sun, 29 Jul 2018 11:54:12 +0200 X-Provags-ID: V03:K1:pE5eSQdwBpGH4tnv4rK9YrjkzqS95AqjZdQck/Rgl2I6yDKxrrU 4n5vLAWBSiKjPmQn6LS+qRol/40vX/AJeqWCKRBuHWPPhFFsCa+RPPLFNVBaP+QjvfS71gP TyuIUDCCNhpWMFPMi/y/t9CROm5s7oNFFeDW1C7IfIA+3waHEt6cNo4rUTJ2MFebOKy/Mdi DzvDlKlsb+NO/uwkFtHVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:PBJm44bfdEg=:GJZGvCkfPZHB+BzV6EvxXT miibBiBscWc51CDhy9gxC1DHXL5ibzRjqtjKVHMiXXV2JC7WXSp5C/ls7kMo8TZBWCzuIBaY0 c/fN0VbGoXoDjyIy7hYE9ZKsm00UdO5VaHF9VxGsXDscc+Rx3Ht0XgEMsw5adD+NW+4UzY58Z Q7mcuFU6q9tyFPLWRLfT6fskM4NQXgsSa/CcLJeKpLsPgYOhxlF1L54Kkj+yGGkDt4+Ovkj6N 542Jzul4wMVeQ7QGf8sgBRtSZFUuWlZyLu80O5N63a6UVP2J2YGk5/R4NA+bNgtqY83rBcNDB bBw/0ZXbjmAjSA+3DiJRoUCdGN0Pjf3ZeNYuO4zMRjscHj02wH+11rcf/MolyTWIL3AY+BJDP qSl4NWhnZ77qeYZ52jbBst66FFf+JK7YCWQ89sFPHxi3kus834n42z5qLvlGDc4U5Ddg6te9/ rWgl0l8BEZfARLeeRl8h72l9L6ccbZ8VGa5GdZBEV9rUIhFsR5EJDnJMAsq7fXpbk4cifGT5J RyCxvYtkxpnpKvxvdd9jdwsF6sQYQQQSaQY69TerTKX8hOlU4VGMRHs0nKjm3hBhMfNo8wPOq tL6DhNDJynyxkAQ43HEfUUz3VYzZt4YdE7BNYBdfaRue9Y2Ij76uKC9C1bkxVnbuhTGSph50u NJtSX73G6OtYOvBJP+jFqv2KHLqIbmS/56XG2v1ci3FSC6G09Egu9p+Mnd3c8feWIZVHaBe+c gR8C4ZfNKD/q/XtozkqxuxktLF+RZ04l4ZcuCdhh3ToW51ugR+cxocAsGllXYw7EtQGm+TOz X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227941 Archived-At: Dmitry Gutov writes: Hi Dmitry, > Third-party code can do that, too. Such as diff-hl, and other packages > not in GNU ELPA. I don't know if any of them call vc-refresh-state, > but it would be nice if > > (progn > (vc-refresh-state) > (vc-state)) > > always returned a predictable, up-to-date result. vc-refresh-state works over the current buffer, vc-state works over a file (which is missing in your example). I don't see after a short look in the sources, how they depend. The result of your code snippet would always be the result of vc-state, which is not threaded. >> Well, you are much more experienced with vc than I do. Look at the >> changes I've done in vc-hooks.el, and adapt. > > I'm not well-versed on the use of Emacs threads, though. Yet. Me too, some weeks ago :-) It isn't that hard. >> The only other relevant change I've done is, that I lock the vc-mutex in >> find-file-with-threads of files.el. This reorders the threads, all >> vc-refresh-state calls are performed after all files (from a wildcard) >> are loaded into their respective buffers. This improves early visibility >> of the visited files. > > Do we actually want one global mutex? What if we had one mutex per > file? Doing those process calls in parallel would be faster, no? One mutex per file isn't necessary; vc-refresh-state is already blocked per file (buffer), because it is called only at the very end of any file visiting command. But you are right, the vc-refresh-state calls shall run in parallel. So I have changed to lock them via vc-mutex only at thread entry, unlock happens immediately. This still ensures that all vc-refresh-state threads run only after all files have been loaded into their buffers, but then they can run in parallel. Best regards, Michael.