Re: [PATCH] Support threads in modules

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 22. Apr. 2017 um 21:49 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 22 Apr 2017 19:21:35 +0000
> > Cc: emacs-devel@gnu.org, phst@google.com
> >
> >  Can you explain the purpose of these changes and the motivation? A
> >  module shouldn't be restricted to be used by a single thread, should
> >  it?
> >
> > No, but the thread used to create an environment object, the current
> Emacs thread, and the current OS thread
> > all have to match. Right now this isn't checked; the current code checks
> only for the main thread, which isn't
> > correct any more now that there can be more than one interpreter thread.
>
> 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. It's not
impossible, but a large burden on module authors.
- The more restrictive the module API is, the more freedom we have in the
implementation.
- The current check is easy to implement and understand. A check for
multiple threads would require another hash table with thread IDs etc.
- 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).
We should stick to the JNI semantics wherever possible, because JNI is a
well-tested and robust technology.

[-- Attachment #2: Type: text/html, Size: 2261 bytes --]