Re: Releasing the thread global_lock from the module API

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 01 Mar 2024 14:51:01 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?

Where would you take the data for opening the socket? doesn't that
come from some Lisp program or from a Lisp variable?  And how would
you know what kind of request to send? doesn't that come from Lisp as
well?  And what would you do with the stuff you get in response? don't
you want to put this in some Lisp variable or provide as input for
some Lisp program?  Etc. etc.

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

Once again: what cannot you do from a native thread started by the
module?  IOW, why would you need access to the global lock machinery
in the first place, if all you want to do is something that is
unrelated to Emacs and its global state?

The code which manipulates the global lock is extremely fragile, so
exposing this to external agents without a very good reason and
without being able to fore some discipline is a bad idea.  And I don't
yet see such a good reason, let alone how to do that in a way that
will preserve the discipline of taking and releasing the lock.  So
please do try to explain better why native threads that are unrelated
to the lock are not the solution for what you have in mind.