Re: "Asynchronous Requests from Emacs Dynamic Modules"

[Eli Zaretskii]

> From: Akira Kyle <ak@akirakyle.com>
> Cc: yyoncho@gmail.com, all_but_last@163.com, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca, p.stephani2@gmail.com
> Date: Sun, 01 Nov 2020 13:15:43 -0700
> 
> Sorry I meant not that it directly exposes pthreads but that its 
> interface is modeled off of pthreads (i.e. mutexes, condition 
> variables), but lisp should really have some higher level 
> interface to parallel and concurrent execution (like Python's 
> multiprocessing or asyncio interface). Perhaps it can be built on 
> top of the current lisp threading interface, but it seems there 
> may be some limitations that make that difficult.

Maybe it can, but I'm not sure I see the need yet.  What exactly is
wrong with the existing primitives?  After all, the Lisp threads _are_
threads, so basic thread operations for them do make sense.

> > The main use case is to allow you to write one or more background
> > Lisp programs that go about their job while a foreground command
> > lets the user interact normally with Emacs.
> 
> Right, but due to the global lock this only allows for concurrent 
> execution, and due to the cooperative nature needing one to 
> explicitly yield execution for threads to switch, it seems like in 
> reality it would be very cumbersome to work with.

Emacs yields automatically when it waits for input, so the idea was
that it wouldn't be cumbersome.

> Do you know of anyone who uses it? I'd be very interested in seeing
> some examples how to successfully use it.

Michael Albinus did, I think you can see his work on a branch in our
Git repository.

> I think libraries like emacs-aio [1] accomplish the same thing but 
> with a much easier to use interface. By using (run-at-time 0 nil 
> callback args) they accomplish a sort of "green threading" that 
> doesn't actually need any sort of pthread support or the 
> associated issues with ensuring atomicity with the interpreter. It 
> would be great to have something like this built in.

run-at-time is our poor man's threading from years ago; Lisp threads
were supposed to make such background applications easier to
implement.