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: Mon, 01 Dec 2008 00:09:36 +0100 Message-ID: <87abbg7qvj.fsf@master.homenet> References: <87abbiody1.fsf@master.homenet> <877i6l5d8s.fsf@master.homenet> <87prkcetze.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228086628 529 80.91.229.12 (30 Nov 2008 23:10:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2008 23:10:28 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 00:11:31 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 1L6vRm-0002mU-Tg for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2008 00:11:27 +0100 Original-Received: from localhost ([127.0.0.1]:51510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6vQc-0008Uc-Ry for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2008 18:10:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6vQD-0008Bx-Rm for emacs-devel@gnu.org; Sun, 30 Nov 2008 18:09:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6vQC-00089i-1q for emacs-devel@gnu.org; Sun, 30 Nov 2008 18:09:49 -0500 Original-Received: from [199.232.76.173] (port=48721 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6vQB-00089W-Uq for emacs-devel@gnu.org; Sun, 30 Nov 2008 18:09:48 -0500 Original-Received: from averell.mail.tiscali.it ([213.205.33.55]:35957) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6vQ8-00035c-2y; Sun, 30 Nov 2008 18:09:44 -0500 Original-Received: from master.homenet (84.222.170.194) by averell.mail.tiscali.it (8.0.022) id 48F7489F01FCE9F5; Mon, 1 Dec 2008 00:09:43 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1L6vQ0-0007ZW-Ll; Mon, 01 Dec 2008 00:09:36 +0100 In-Reply-To: <87prkcetze.fsf@catnip.gol.com> (Miles Bader's message of "Mon, 01 Dec 2008 07:20:37 +0900") 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:106350 Archived-At: Miles Bader writes: > BTW, there was a huge thread maybe a year (?) or so ago about this subject. > Have you read it? > > IIRC, the basic consensus was that some sort of explicitly > non-preemptive threading was probably the best solution for emacs. > > -Miles I found a thread of 3 years ago (maybe is it this one? Time passes very fast :) ) but I didn't find any conclusion. Anyway, a non-preemptive threading will not give any real parallelism and it will require more changes in the Elisp packages to use threads as they will need to say explicitly when give the control to another thread. Instead `run-in-thread' will setup the call stack and finally give the control to the thread. The only change required in the Elisp packages to be used in a multithreaded environment is to protect global data accesses with a lock/unlock, but how many times does it happen to change the value of a global variable? Both solutions require changes in Elisp, a non-preemptive threading needs to explicitly yield the control to another thread, while having real threads needs to specify when access to global data must be protected. The latter one differently allows parallelism and I guess less changes in the Elisp code too (if writes to global data are less frequent than specify when exit from the current thread). Giuseppe