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 19:57:44 +0100 Message-ID: <874p1npvtj.fsf@master.homenet> References: <87abbiody1.fsf@master.homenet> <877i6l5d8s.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 1228157892 13008 80.91.229.12 (1 Dec 2008 18:58:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2008 18:58:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 19:59:16 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 1L7DzG-0000lX-5Q for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2008 19:59:14 +0100 Original-Received: from localhost ([127.0.0.1]:47188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7Dy5-0006cM-RQ for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2008 13:58:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7Dy0-0006c4-8m for emacs-devel@gnu.org; Mon, 01 Dec 2008 13:57:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7Dxy-0006bs-I4 for emacs-devel@gnu.org; Mon, 01 Dec 2008 13:57:55 -0500 Original-Received: from [199.232.76.173] (port=33949 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7Dxy-0006bp-CR for emacs-devel@gnu.org; Mon, 01 Dec 2008 13:57:54 -0500 Original-Received: from jack.mail.tiscali.it ([213.205.33.53]:59718) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L7Dxw-0001ou-9N; Mon, 01 Dec 2008 13:57:52 -0500 Original-Received: from master.homenet (84.222.170.194) by jack.mail.tiscali.it (8.0.022) id 48F74810022AA346; Mon, 1 Dec 2008 19:57:51 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1L7Dxp-0000oq-25; Mon, 01 Dec 2008 19:57:45 +0100 In-Reply-To: (Richard M. Stallman's message of "Mon, 01 Dec 2008 09:06:54 -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:106396 Archived-At: Richard M Stallman writes: > I don't think we want to make such pervasive and inconvenient changes > in the C code. What we want, I think, is to allow thread switches > only inside the QUIT macro. If we don't want to do immediately all changes at one time and proceed slowly to a real parallelism then we can start with a concurrent threads model. I think that concurrent threads can't be considered the final solution, what I would like to optimize using threads is I/O bound and a concurrent model can do it only in part. If an Elisp primitive is waiting for some data from a file or a socket, Emacs will hang until it is ready. This problem can't be solved by concurrent threads that will switch only inside the QUIT macro. If we will implement a concurrent threads model and introduce the QUIT macro after it can't be used by parallel threads as accesses to shared data must be synchronized differently. IMHO, concurrent threads itself are not very useful, they can be useful if considered a first step in the direction of a real parallelism. I know it is a lot of work and the question (as in everything) is: does benefits we will have worth this effort? Regards, Giuseppe