From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Mon, 17 Oct 2016 10:13:22 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87oa2jgj25.fsf@lifelogs.com> References: <87wq97i78i.fsf@earlgrey.lan> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> <83mvi9a3mh.fsf@gnu.org> <20161012165911.58437154@jabberwock.cb.piermont.com> <20161012173314.799d1dc5@jabberwock.cb.piermont.com> <8360owaj2s.fsf@gnu.org> <20161013092701.77461800@jabberwock.cb.piermont.com> <87insvt0i9.fsf@lifelogs.com> <87zim7hr06.fsf@gmx.de> <87eg3iu7nl.fsf@lifelogs.com> <87k2darsjo.fsf@gmx.de> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476713685 20022 195.159.176.226 (17 Oct 2016 14:14:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Oct 2016 14:14:45 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 17 16:14:41 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 1bw8gH-0002EN-T0 for ged-emacs-devel@m.gmane.org; Mon, 17 Oct 2016 16:14:22 +0200 Original-Received: from localhost ([::1]:33344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw8gK-0002j2-0h for ged-emacs-devel@m.gmane.org; Mon, 17 Oct 2016 10:14:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw8g6-0002gR-MD for emacs-devel@gnu.org; Mon, 17 Oct 2016 10:14:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bw8g2-0003Ii-L3 for emacs-devel@gnu.org; Mon, 17 Oct 2016 10:14:10 -0400 Original-Received: from [195.159.176.226] (port=46645 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bw8g2-0003IE-EK for emacs-devel@gnu.org; Mon, 17 Oct 2016 10:14:06 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bw8fi-0006pd-Gj for emacs-devel@gnu.org; Mon, 17 Oct 2016 16:13:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 38 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:15v8xjH/SbAN2Vl1W+2fo5vgSxY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:208355 Archived-At: On Sat, 15 Oct 2016 09:16:11 +0200 Michael Albinus wrote: MA> Ted Zlatanov writes: >> I'm also not sure if Tramp would be asynchronous when a Tramp method >> used just core functions, no process. MA> There are Tramp methods like "scp", which use already a second MA> asynchronous process for copying files internally. This could be exposed MA> to the user easily, once we have an asynchronous `copy-file-*' MA> interface. I have a suggestion, crossing into implementation. I hope that's somewhat useful. Rather than a special function, the new copy-file could simply return a Future of some sort. Sebastian Weisner suggested that general approach; I think Futures are a good API based on my experience. Here's how I would implement it. The usage could be like this: 1) fully backwards compatible: (use value of (copy-file ...)) -> collects the Future, blocking until it's available 2) (with-future (copy-file ...) -> makes local functions available inside the macro to check if the value is available, like (future-is-ready) or whatever. This can provide voluntary yields based on the availability of the future. 3) (setq ((f (future (copy-file ...))))) -> capture Future in f, do voluntary yields on it, etc. The key is that unless you are aware of Futures, you'll get the collected value. I think that's the easiest way to provide the async functionality without breaking code or adding new API functions to every library out there. Ted