Re: async 1.0

[John Wiegley]

>>>>> Michael Albinus <address@hidden> writes:

> Or you keep the Emacs daemons running in the background, waiting for new
> tasks. Communication could be via D-Bus (queued services). But I have no
> idea, how much it would improve reactiveness.
> 
> And it wouldn't run on all platforms Emacs supports.

And it introduces state bugs, which would be insane to debug, since presently
there is no a way to debug the child Emacs.  I'm having a hard time even
getting stack traces from the point of failure (a condition-case handler gives
you the backtrace for the handler, not the error's origin.  This may need new
functionality in Emacs to pass the trace as part of the error data).

I've been talking with someone else who is interested in creating a Swank
backend for Elisp that would make such debugging possible, but even then it's
not something I'd want to rely on after only the 20th `async-start' call
failed, though all the prior ones had succeeded...

The startup cost for async Emacs is currently dwarfed by the size of the tasks
I'm using it for.  If your async job is only running for a few hundred
milliseconds, I would say don't use async.el for that job, rather than trying
to optimize that case.

John