Eli Zaretskii <
address@hidden> schrieb am Sa., 22. Apr. 2017 um 21:49 Uhr:
> From: Philipp Stephani <address@hidden>
> Date: Sat, 22 Apr 2017 19:21:35 +0000
> Cc: address@hidden, address@hidden
>
> 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.