Re: Concurrency, again

[Ted Zlatanov]

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