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: Tue, 09 Dec 2008 20:10:37 +0100 Message-ID: <87myf5p3ki.fsf@master.homenet> References: <87abbiody1.fsf@master.homenet> <877i6l5d8s.fsf@master.homenet> <874p1npvtj.fsf@master.homenet> <87ej0qci8g.fsf@master.homenet> <87y6yxm7xr.fsf@master.homenet> <87hc5gyn9x.fsf@master.homenet> <87ej0ixx97.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 1228849882 8301 80.91.229.12 (9 Dec 2008 19:11:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2008 19:11:22 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 09 20:12:26 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 1LA80E-0001bW-7G for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2008 20:12:14 +0100 Original-Received: from localhost ([127.0.0.1]:43502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LA7z2-000853-VF for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2008 14:11:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LA7yw-00084U-Ri for emacs-devel@gnu.org; Tue, 09 Dec 2008 14:10:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LA7yu-00084F-VP for emacs-devel@gnu.org; Tue, 09 Dec 2008 14:10:53 -0500 Original-Received: from [199.232.76.173] (port=37453 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LA7yu-00084C-Qi for emacs-devel@gnu.org; Tue, 09 Dec 2008 14:10:52 -0500 Original-Received: from joe.mail.tiscali.it ([213.205.33.54]:48514) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LA7yp-0008MV-EE; Tue, 09 Dec 2008 14:10:47 -0500 Original-Received: from master.homenet (84.222.170.109) by joe.mail.tiscali.it (8.0.022) id 48F7490702C320A9; Tue, 9 Dec 2008 20:10:45 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1LA7yf-00011m-Mc; Tue, 09 Dec 2008 20:10:37 +0100 In-Reply-To: (Richard M. Stallman's message of "Tue, 09 Dec 2008 12:26:28 -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:106725 Archived-At: Richard M Stallman writes: > > What is the condition for thread-switching in your latest version? > > The `yield' primitive must be explicitly called. > > I think that interface won't work very well, because it would require > changing every Lisp program to make it cooperate with other threads. > We need to put this into the C level. I think it is not safe to call `yield' from the C code, except special cases like `run-in-thread'. Every thread must be completely separated from each other to allow a switch during its execution and it is not true while threads are accessing global variables. For example, we can't switch threads while they are executing: (setq a-global-variable (foo a-global-variable)) This is the reason why YIELD must be explicit at Elisp level, because the developer knows exactly that a switch can happen at that point. In future every thread should be executed indipendently from each other (adding synchronization primitives where they are needed) to allow real parallelism. > If making QUIT do this is not safe, we could write another macro > YIELD to do it, and call that macro where appropriate. > > But that macro needs to be very fast when it does NOT switch threads! Elisp developers shouldn't worry about yield efficiency because if there are not other active threads, nothing will be done and `yield' returns immediately. > Here's an idea. Suppose the YIELD macro increments a counter and > switches threads (round robin?) when that counter reaches a certain > number. Every thread-switch would reset the counter to 0. > Of course, waiting (in wait_reading_process_output) would also > switch threads. Thread switching is implemented using round robin. Why would you like to reduce the amount of switches using a counter? I think that thread switching doesn't take a lot of time that we need to call it carefully, instead I think that more often we call it and more responsive Emacs will look. I was thinking about change the scheduler policy to give a bigger priority to threads that are working on a buffer currently visible to the user. What I really expect from Emacs threads is that I can continue working while some other tasks are executed in the background, like fetching emails. Personally I will not care much if it took N+1 seconds instead of N if I could continue work on another buffer. Giuseppe