Re: "Asynchronous Requests from Emacs Dynamic Modules"

[Akira Kyle]

On Sat, Oct 31, 2020 at 04:43 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

> > That is unfortunate. I was assuming that at least thread 
> > primitives can be made thread-safe. 
>
> They are thread-safe, but they rely on strict discipline of 
> having
> one, and only one, Lisp thread active at any given time.  IOW, 
> the
> mechanism that switches threads is not "thread-safe".

To summarize so far, I see three different ways of tackling this:

1) Chris Wellon's solution in the article I linked using the 
SIGUSR1 signal which Emacs handles in the event queue notify the 
running Lisp Thread that it should call back into module 
functions. This idea could be expanded to allow modules to define 
their own events and lisp handlers that will respond to them.

2) Stefan's and Philipp's proposal of using the process interface 
with file descriptors to pipes and perhaps `process-filter` to 
notify the Lisp Thread that it should call back into the module 
functions.

3) yyoncho's proposal to use the lisp threading interface, 
specifically condition variables to allow dynamic modules to 
`condition-notify`.

I see advantages and disadvantages to each. I think the most 
natural solution would be a dynamic module interface that allows 
grabbing and releasing Lisp's global thread lock. I think this 
would simplify writing dynamic module functions which could 
potentially cause Emacs to hang as it wouldn't require module 
authors to think about the lisp machinery to figure out what 
module function with what state to call back into when it needs to 
get its result back into lisp land. The way such an interface is 
implemented could be with any of the above mechanisms or something 
else.