bug#42028: [Feature Request] 27.0.91; Provide the ability dynamic modules to post events in emacs event loop

[Ivan Yonchovski]

Eli Zaretskii writes:

> Does it?  Did someone time these separately?

IDK, this was just an example.

>> start(string, callback) -> convert string to char* -> post it to worker 
>> thread -> worker thread does the parsing
>> -> worker thread post to main loop -> main loop converts Jansson ds to lisp 
>> ds -> main loop
>> calls the callback passed on start
>
> You cannot easily post to the queue from a worker thread, because the
> queue cannot be posted to asynchronously.

AFAIK this is not possible at all - thus this feature request.

>
> And I lack the larger picture: how would this work within a framework
> of some Emacs feature?  E.g., how will this processed be triggered,
> and by what kind of trigger?

The goal users to be able to handle more usecases. ATM the only way to
achieve that is hackish as described here
https://nullprogram.com/blog/2017/02/14/ + several practical usecases.


> Again, I don't see the wider picture.  Are you familiar with how the
> current JIT font-lock works?  If so, can you explain which parts of
> that will be replaced/modified, and how?

AFAIK the initial tree-sitter parsing (which does not involve anything
emacs related) may take 200-300ms. In other editors (e.g. vscode) this
part is not happening on the UI thread but in some extenal background
thread which then passes the AST to the main UI thread to do the actual
fontlock. IMO this model might be replicated in emacs in the event of TS
integration.

Thanks,
Ivan