Eli Zaretskii schrieb am Sa., 22. Apr. 2017 um 21:49 Uhr: > > From: Philipp Stephani > > 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.