From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Please test the merge of the concurrency branch Date: Sun, 11 Dec 2016 17:45:32 +0200 Message-ID: <83oa0ieag3.fsf@gnu.org> References: <83oa0lgnzx.fsf@gnu.org> <195DE508-E3ED-4BF9-AE96-EBE2157EFAAC@raeburn.org> <87eg1eltje.fsf@gmx.de> <6FD3E405-B333-4A4D-8729-63248C7409CC@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1481471114 1743 195.159.176.226 (11 Dec 2016 15:45:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 15:45:14 +0000 (UTC) Cc: tom@tromey.com, michael.albinus@gmx.de, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 16:45:10 2016 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 1cG6JK-0008Dw-1m for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 16:45:10 +0100 Original-Received: from localhost ([::1]:56089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG6JO-0005vE-7Y for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 10:45:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG6JC-0005qp-BR for emacs-devel@gnu.org; Sun, 11 Dec 2016 10:45:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cG6J9-0008Bc-9L for emacs-devel@gnu.org; Sun, 11 Dec 2016 10:45:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG6J9-0008BX-66; Sun, 11 Dec 2016 10:44:59 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3067 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cG6J7-0000Ge-Cc; Sun, 11 Dec 2016 10:44:57 -0500 In-reply-to: <6FD3E405-B333-4A4D-8729-63248C7409CC@raeburn.org> (message from Ken Raeburn on Sun, 11 Dec 2016 08:54:52 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:210280 Archived-At: > From: Ken Raeburn > Date: Sun, 11 Dec 2016 08:54:52 -0500 > Cc: Eli Zaretskii , > Tom Tromey , > emacs-devel@gnu.org > > For example, if I have a couple of threads invoking find-file in a package of mine, and both invocations have Tramp filenames, and the Tramp code has blocking calls (e.g., waiting for subprocess output) that result in thread switching, both threads could be trying to mess around with the same Tramp data structures and subprocess communications, with messy results. Unless we want to tell people “don’t do file operations in more than one thread”, or “don’t do Tramp operations in more than one thread” (in which case people doing file operations need to check whether they’re local files?), maybe Tramp should do some locking internally. And what happens if I invoke “tramp-cleanup-all-connections” while a file-reading operation is in progress? There are synchronization facilities to take care of these. And each thread can have its local bindings of the same variables, which also could help. But yes, making a large package such as Tramp threads-aware will probably take some work.