From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giuseppe Scrivano Newsgroups: gmane.emacs.devel Subject: Re: multi-threaded Emacs Date: Sun, 30 Nov 2008 12:35:10 +0100 Message-ID: <87bpvx5tw1.fsf@master.homenet> References: <87abbiody1.fsf@master.homenet> <873ahant5l.fsf@master.homenet> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228044956 9876 80.91.229.12 (30 Nov 2008 11:35:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2008 11:35:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 30 12:37:01 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L6kbk-0006jO-28 for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2008 12:37:00 +0100 Original-Received: from localhost ([127.0.0.1]:43907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6kaZ-00030N-MD for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2008 06:35:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6kaC-0002zO-Qa for emacs-devel@gnu.org; Sun, 30 Nov 2008 06:35:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6ka9-0002yo-8r for emacs-devel@gnu.org; Sun, 30 Nov 2008 06:35:22 -0500 Original-Received: from [199.232.76.173] (port=35241 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6ka8-0002yb-6P for emacs-devel@gnu.org; Sun, 30 Nov 2008 06:35:20 -0500 Original-Received: from averell.mail.tiscali.it ([213.205.33.55]:60006) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6ka7-0002B1-Ht for emacs-devel@gnu.org; Sun, 30 Nov 2008 06:35:19 -0500 Original-Received: from master.homenet (84.222.171.4) by averell.mail.tiscali.it (8.0.022) id 48F7489F01F9F25C; Sun, 30 Nov 2008 12:35:16 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1L6kZy-0001VZ-GJ; Sun, 30 Nov 2008 12:35:10 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 29 Nov 2008 17:21:51 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106334 Archived-At: Hello, Stefan Monnier writes: > Currently, we basically use the following implementation: > > (defun get-var (sym) > (symbol-value 'var)) > (defun set-var (sym val) > (setf (symbol-value 'var) val)) > (defmacro let-var (sym val body) > `(let ((oldval (get-var ,sym))) > (set-var ,sym ,val) > (unwind-protect > ,body > (set-var ,sym ,val)))) > > we could instead use something like > > (defun get-var (sym) > (cdr (assq sym specpdl))) > (defun set-var (sym val) > (set-cdr (assq sym specpdl) val)) > (defmacro let-var (sym val body) > `(let ((oldpdl specpdl)) > (push (cons ,sym ,val) specpdl) > (unwind-protect > ,body > (setq specpdl oldpdl)))) > > where specpdl is a per-thread variable. Or > > (defun get-var (sym) > (cdr (assq thread (symbol-value sym)))) > (defun set-var (sym val) > (set-cdr (assq thread (symbol-value sym)) val)) > (defmacro let-var (sym val body) > `(let ((oldval (get-var ,sym))) > (set-var ,sym ,val) > (unwind-protect > ,body > (set-var ,sym ,val)))) > > This latter one might be the simplest: it basically adapts the > notion of buffer-local/frame-local/terminal-local to also include > thread-local. Currently, only one form of locality is supported at > a time (a var can't be both buffer-local and terminal-local), so this > would need to be worked out (frame-local and buffer-local was allowed > in Emacs-21 but its behavior was not clearly defined and had corner > case bugs). I don't think that thread-local data has the same meaning as buffer-local, frame-local or terminal-local. Thread-local data should be handled transparently to the user, I don't see it very useful (if not dangerous) to give the possibility to store data on a specific thread beside temporary variables. Probably it is good idea to modify `with-thread' to don't accept a thread id, but simply the code to execute on a different thread, the caller thread local bindings will be copied to the called thread. Do you see any situation that there is need to store a value on a specific thread? > I'm not sure what you mean by "a global lock". The question is not only > how many locks, but what they protect. My proposal further down to > start with "only one thread active at a time" is what I'd call "a global > lock". If we use a lock (or locks) to protect shared data still threads can be executed in parallel while they working on thread local data. On the other hand, with only one active thread we are sure that we are not forgetting to protect something. Thanks, Giuseppe