Re: Concurrency, again

[John Wiegley]

>>>>> "MA" == Michael Albinus <address@hidden> writes:

MA> The point of Tramp is not to use additional power of sleeping cores, but
MA> waiting for slow connections. One could already make some of its handlers
MA> asynchronously as of today, but a proper API is missing. All callers of
MA> (for example) `copy-file' expect, that the function has finished once it
MA> returns. We would need another `copy-file-asynchronously', which offers
MA> also a handler to be called once the copying has finished.

Btw, this is just what I did in dired-async, and it works well enough there.
The code looks roughly like this (somewhat simplified):

      (async-start
       ;; lambda form executed in the child process
       `(lambda ()
          (require 'cl-lib)
          (require 'dired-aux)
          (require 'dired-x)
          ,(async-inject-variables dired-async-env-variables-regexp)
          (condition-case err
              (copy-file from to ok dired-copy-preserve-time)
            (file-date-error
             (dired-log "Can't set date on %s:\n%s\n" from err)))
          ,(dired-async-maybe-kill-ftp))

       ;; the callback
       (lambda (&optional _ignore)
         (dired-async-after-file-create
          total (list operation (length async-fn-list)) failures skipped)))

So, you can do what you mentioned today. Maybe a better solution would be to
move this support into C and support direct transmission of values into the
child process over IPC, rather than streaming them as text across a file
handle, as it does now.

Further, I'm not sure if the concurrency branch would actually execute
`copy-file` asynchronously; Emacs might still block at some point during the
copy, since there's a GIL preventing threads from executing at the same time.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2