[Arcana] John Wiegley just blew my mind.

Karl Fogel kfogel at red-bean.com
Fri Jun 22 18:00:57 CDT 2012

Roland McGrath <roland at frob.com> writes:
>P'shaw (and whippersnappers).  Sending a form to an entirely different
>Emacs process is a far cry from anything that really stands in for thread
>support.  Just see how long it takes someone to write something that uses
>async-start to run an asynchronous function that wants to use a buffer, or
>global variables with interesting state, etc.

Well, to be fair, he's aware:

  > You know, Emacs is suprisingly fast to execute if you use "emacs
  > -batch -Q".  For example:
  >     vulcan ~ $ average -n 100 emacs -Q -batch --eval "(+ 10 20)"
  >     0.0393513631821
  > It's only 39.4ms overhead per invocation to use Emacs this way --
  > plus the time required load modules used by the async process, and
  > injection of the variable environment.  For example:
  >     vulcan ~ $ average -n 100 emacs -Q -batch \
  >                     --eval "(progn (require 'smtpmail) (+ 10 20))"
  >     0.143285052776
  > Now we're up to 143ms.  What makes this OK is that the job I'm
  > asking `async-start' to do takes many seconds, such that the
  > overhead of starting a new Emacs interpreter is completely lost in
  > the time required to do the work -- time otherwise spent with me
  > staring at a wait cursor.
  > As a further example: In Gnus, hitting M-g on the emacs-devel group
  > takes around 60s (I have a lot of back articles).  If async.el were
  > integrated, this operation would return instantly, with some kind of
  > fontification to show the group being updated in the background, and
  > blocking behavior if I hit RET to actually visit the group before
  > it's done.
  > That's kind of how dired-async.el operates now: When you copy a
  > bunch of large files, control returns to you immediately, and each
  > file is colorized with a yellow background that gets removed once
  > that copy operation is completed.
  [...later message...]
  >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.

>Of course, if he had call/cc in elisp he could just implement asynchrony
>using continuation capture in various blocking calls, the idle hook, etc.
>But given the nature of Emacs's interpreter, implementing call/cc is
>dubiously feasible at best.  One can imagine something like the old SCM
>trick of copying the C stack, in an unholy marriage with some underhanded
>fiddling of the GCPRO machinery, and then some scheme (ahem) to avoid
>leaking everything if the continuation object is dropped before application
>(and what about GCPRO vs multiple applications??).  And those are just the
>gotchas that leap to mind for someone who has barely looked at the Emacs
>implementation in over 15 years.

The GCPRO point is... hard, yes.  Not fatal.  But very hard.

>So, um, sorry, and I'm sure a man named Wiegley has got to be just lovely,
>but I'll consider your mind defellated.

He also wrote 'ledger', the command line double-entry bookkeeping
software on which I'm now completely dependent.  And he singlehandedly
prevented the Icelandic Genocide of 1952, which you've never heard of
because he prevented it.  So lay off, man.

More information about the Arcana mailing list