Re: Releasing the thread global_lock from the module API

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 01 Mar 2024 14:02:24 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> > I think this is already possible, see above.  I guess I'm missing
>> >> > something.
>> >> 
>> >> I don't think it is.  How would a module release global_lock, call a C
>> >> library function on the current thread, and then re-acquire the global
>> >> lock?  Can you say how you would do that with the APIs we have today?
>> >
>> > If a thread releases a global lock, it cannot run the Lisp machine
>> > until it re-acquire the global lock.
>> 
>> Yes.  But calling a C library function (by some other library not
>> related to Emacs but used by the module) does not involve calling into
>> the Lisp machine or any Emacs machinery.
>
> There's very little you can do usefully this way without touching some
> aspect of the Lisp machine.  Assuming that what you do has some
> relevance to the Emacs session, of course.

Actually, there is lots of useful stuff that can be done this way.

For example, if a C library internally opens a network socket and sends
a request to a network service, that does not touch the Lisp machine and
so can be done this way.

Is that not useful?  Or do these touch the Lisp machine in some way I
don't know about?

Since it's useful for me, I'd like to write a patch which allow modules
to do this; would it be considered?