From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Please test the merge of the concurrency branch Date: Sun, 11 Dec 2016 08:54:52 -0500 Message-ID: <6FD3E405-B333-4A4D-8729-63248C7409CC@raeburn.org> References: <83oa0lgnzx.fsf@gnu.org> <195DE508-E3ED-4BF9-AE96-EBE2157EFAAC@raeburn.org> <87eg1eltje.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1481464597 5102 195.159.176.226 (11 Dec 2016 13:56:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 13:56:37 +0000 (UTC) Cc: Eli Zaretskii , Tom Tromey , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 14:56:33 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 1cG4cD-0000TD-AI for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 14:56:33 +0100 Original-Received: from localhost ([::1]:55807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG4cH-0004Vb-I9 for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 08:56:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG4bf-0004VU-90 for emacs-devel@gnu.org; Sun, 11 Dec 2016 08:56:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cG4bc-00009o-6a for emacs-devel@gnu.org; Sun, 11 Dec 2016 08:55:59 -0500 Original-Received: from mail-qk0-f196.google.com ([209.85.220.196]:36572) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cG4bc-00009P-16 for emacs-devel@gnu.org; Sun, 11 Dec 2016 08:55:56 -0500 Original-Received: by mail-qk0-f196.google.com with SMTP id h201so7645789qke.3 for ; Sun, 11 Dec 2016 05:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0+9E2BkNwuIMJE1Pkjn/Sw2Yq9A5v1ox1Ndvte3HvI=; b=GVQGIaB3azwNweyohyDxXWFRFnoU8Qm7PUjm6b+tyKr4bx/2b6OjkLhxFu4AOWzZ2n N1iWtZtBy4Z+g3VOtiy55LXrKyHOwuR6rFZtfFv0XvWnHNVBorfK7enAHz61IoGqfpuD 4wlPm8gxmEK2PzpWxJdsRHv9W+zGj57ZIN18mH/FeiM21rtR63PgOoDmk+4kQJ/FaNlf 7cqGMU3UNkoqucCJnFSj6qanRpo9Ko49STO57TX+OGuWqe5Xpwwry1mR9HOV9IevMlJc du6YMNbZ/FeC8Kr4g7LWbIUFOE8yr/d2asY5gZaZSgk8te7HG409wVgH4RuqSA39SIAb L/Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z0+9E2BkNwuIMJE1Pkjn/Sw2Yq9A5v1ox1Ndvte3HvI=; b=SedZp7xcVp9M0xP6rowC0KJTs9DuOWFHTxAnC1OLMcTwI8Hk+wLaOfjua4PzbgEy9F 1aSUgDisrS0hCLinCtSEyeYNFDYkRwc1YHTxz0klPs4ot5rV+U7mElmgc6Qu77x82PNt jku0PV/znr1RXrv1hEGn/2qDPp+MsB2s1FexlnuwLVws0d8i2F/jD+Sc+suJuofVD4vB pTa/R6AASlWfDkA8VVogdKRzW3vMHvqBNdDaBglpzH5kywP6aCVI7kXTUtiShzLdut2j eVS+d2ZjnCFhd+/4rGeGiUVBau0tFbl14m72IMszhTUuMGTCIyoob/V/eDUo65GkX94B /5xA== X-Gm-Message-State: AKaTC025t2EXhW9s+Na2C3/qA27rpzr4MEaTe3FKecTZ0Lhj2imZfnwuBk/x10R5Lyqy+Q== X-Received: by 10.55.11.140 with SMTP id 134mr14335141qkl.236.1481464494987; Sun, 11 Dec 2016 05:54:54 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id p19sm24432391qtp.4.2016.12.11.05.54.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Dec 2016 05:54:53 -0800 (PST) In-Reply-To: <87eg1eltje.fsf@gmx.de> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.220.196 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:210269 Archived-At: On Dec 11, 2016, at 04:11, Michael Albinus = wrote: > Ken Raeburn writes: >=20 >> The branch builds & runs fine for me on Mac OS X 10.11.6 (i.e., one >> major release out of date). Only tested with a few hours of normal >> code editing work locally and via TRAMP so far though. >=20 > When time permits I'll check how Tramp could profit from the > concurrency. First I'll release Tramp 2.3.1, so it might still take a > couple of weeks. There are still some basic bugs to work out=E2=80=A6 > If people have proposals what to change in Tramp wrt concurrency, = please > say so. Of course I know that, for example, file copying shall not = block > further Emacs use, but I'm still uncertain how to integrate this. As = of > today, all callers of `copy-file' and friends do expect, that the > copying has finished once the function returns. Given that it=E2=80=99s an optional feature at this point (and not = supported by every OS), I=E2=80=99d be careful in how you try to make = use of it. In fact, Tramp is one of the areas where you might want to consider = whether some, ah, defensive changes might be wise first. 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 =E2=80=9Cdon=E2=80=99t do file = operations in more than one thread=E2=80=9D, or =E2=80=9Cdon=E2=80=99t = do Tramp operations in more than one thread=E2=80=9D (in which case = people doing file operations need to check whether they=E2=80=99re local = files?), maybe Tramp should do some locking internally. And what = happens if I invoke =E2=80=9Ctramp-cleanup-all-connections=E2=80=9D = while a file-reading operation is in progress? There are probably other parts of the Lisp library in a similar = position, but the ones coming to mind offhand would probably generally = be used in more direct fashion, whereas Tramp often hides under the = normal file abstractions. Ken=