Re: [PATCH] Support threads in modules

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 22 Apr 2017 20:05:19 +0000
> Cc: emacs-devel@gnu.org, phst@google.com
> 
>  I agree that checking for the main thread is not TRT, but why not
>  allow any thread of those in all_threads? Why do we care that the env
>  pointer was created by the same thread as the one using it? We should
>  only care that the invoking thread is one of the Emacs application
>  threads, no?
> 
> - Using objects across threads requires careful synchronization.

Not sure what synchronization you have in mind.  There's only one
running thread at any given time, and a thread cannot be preempted
while it runs Lisp, so synchronization seems unnecessary, as a thread
cannot modify a Lisp object that another thread is modifying.

> - The more restrictive the module API is, the more freedom we have in the implementation.

I don't think I understand this.  From my POV, restricting modules to
be called only from one thread is too restrictive, and I see no reason
for that.

> - The current check is easy to implement and understand. A check for multiple threads would require another
> hash table with thread IDs etc.

Why do you need a has table?  There's a linked list in all_threads
which holds all the known application threads, we just need a loop
over them.

> - The Emacs module API is modelled after JNI, which has the same restriction
> (http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html).

Themodule API is modelled after JNI, but the threads model is a far
cry from Java threads.  So I don't think this argument is relevant,
unless you can show specific problems with our implementation of
threads.

Modules were added to Emacs to allow easy interfaces to external
libraries.  It makes very little sense to me to arbitrarily restrict
the use of such external libraries in only some threads.  IMO, it's a
grave limitation.