[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency, again
From: |
Ted Zlatanov |
Subject: |
Re: Concurrency, again |
Date: |
Mon, 17 Oct 2016 10:13:22 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
On Sat, 15 Oct 2016 09:16:11 +0200 Michael Albinus <address@hidden> wrote:
MA> Ted Zlatanov <address@hidden> 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
- Re: Concurrency, again, (continued)
- Re: Concurrency, again, Clément Pit--Claudel, 2016/10/13
- Re: Concurrency, again, John Wiegley, 2016/10/13
- Re: Concurrency, again, Ted Zlatanov, 2016/10/14
- Re: Concurrency, again, Michael Albinus, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14
- Re: Concurrency, again, Ted Zlatanov, 2016/10/14
- Re: Concurrency, again, Michael Albinus, 2016/10/15
- Re: Concurrency, again,
Ted Zlatanov <=
- Re: Concurrency, again, Ken Raeburn, 2016/10/17
- Re: Concurrency, again, Stefan Monnier, 2016/10/17
- Re: Concurrency, again, Stefan Huchler, 2016/10/14
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/17
- Re: Concurrency, again, Stefan Huchler, 2016/10/17