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 16:56:55 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Then I would release the lock and call into my library, which does some
> >> useful work which takes a while.
> >
> > How is this different from starting your own native thread, then
> > releasing the lock?
> 
> They are completely different things.

I think there's a misunderstanding here, because I cannot see how they
could be "completely different things."  See below.

> > If a C library provides some blocking function which does some
> > complicated form of IO, a module providing bindings for that C library
> > can release global_lock before calling that function, and then
> > re-acquire the lock after the function returns.  Then Lisp threads
> > calling this module function will not block the main Emacs thread.
> 
> So, if I am running the following program in a Lisp thread:
> 
> (while (do-emacs-things)
>   (let ((input (do-emacs-things)))
>     (let ((result (call-into-native-module input)))
>       (do-emacs-things result))))
> 
> and call-into-native-module unlocks the global lock around the calls
> into my library, then during the part of call-into-native-module which
> calls into my library, the main Emacs thread will not be blocked and can
> run in parallel with call-into-native-module.

I'm saying that your call-into-native-module method could do the
following:

  . start a native thread running the call into your library
  . release the global lock by calling thread-yield or sleep-for or
    any other API which yields to other Lisp threads
  . wait for the native thread to finish
  . return when it succeeds to acquire the global lock following the
    completion of the native thread

The _only_ difference between the above and what you described is that
portions of call-into-native-module are run in a separate native
thread, and the Lisp thread which runs the above snippet keeps
yielding until the native thread finishes its job.  How is this
"completely different"?

> > You didn't answer my question about doing this from a native thread.
> 
> I hope my answer above clarifies it.

I think it demonstrates some significant misunderstanding, which I
how I have now clarified.