From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support threads in modules Date: Sat, 22 Apr 2017 23:14:18 +0300 Message-ID: <83r30kp5d1.fsf@gnu.org> References: <20170422152444.48735-1-phst@google.com> <83zif8p8d3.fsf@gnu.org> <83tw5gp6hy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492892057 8995 195.159.176.226 (22 Apr 2017 20:14:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Apr 2017 20:14:17 +0000 (UTC) Cc: phst@google.com, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 22 22:14:07 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d21Py-00024X-Kx for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 22:14:06 +0200 Original-Received: from localhost ([::1]:36732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d21Q3-0000rR-Up for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 16:14:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d21PW-0000rJ-D7 for emacs-devel@gnu.org; Sat, 22 Apr 2017 16:13:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d21PV-0000UF-A2 for emacs-devel@gnu.org; Sat, 22 Apr 2017 16:13:38 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d21PR-0000TQ-82; Sat, 22 Apr 2017 16:13:33 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4422 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d21PQ-0001Hl-I3; Sat, 22 Apr 2017 16:13:32 -0400 In-reply-to: (message from Philipp Stephani on Sat, 22 Apr 2017 20:05:19 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214227 Archived-At: > From: Philipp Stephani > 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.