Re: Releasing the thread global_lock from the module API

[Eli Zaretskii <eliz@gnu.org>]

> 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.

> So, because it does not involve calling into Emacs, we could allow
> the thread to make that call without the Emacs global lock which
> protects Emacs.

Once again: you can do that if you start a native thread before
releasing the global lock.  Why is that not a solution to what you
have in mind?