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 18:34:43 +0100 Message-ID: <877i6l5d8s.fsf@master.homenet> References: <87abbiody1.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 1228066755 5476 80.91.229.12 (30 Nov 2008 17:39:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2008 17:39:15 +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 Sun Nov 30 18:40:18 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 1L6qHG-0002GZ-9C for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2008 18:40:14 +0100 Original-Received: from localhost ([127.0.0.1]:48173 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6qG6-0002Br-AA for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2008 12:39:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6qC9-0007sb-4W for emacs-devel@gnu.org; Sun, 30 Nov 2008 12:34:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6qC6-0007s6-Pj for emacs-devel@gnu.org; Sun, 30 Nov 2008 12:34:56 -0500 Original-Received: from [199.232.76.173] (port=41476 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6qC6-0007s3-B6 for emacs-devel@gnu.org; Sun, 30 Nov 2008 12:34:54 -0500 Original-Received: from averell.mail.tiscali.it ([213.205.33.55]:34423) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6qC2-0004Ja-62; Sun, 30 Nov 2008 12:34:50 -0500 Original-Received: from master.homenet (84.222.171.4) by averell.mail.tiscali.it (8.0.022) id 48F7489F01FB8362; Sun, 30 Nov 2008 18:34:49 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1L6qBv-0002s9-EH; Sun, 30 Nov 2008 18:34:43 +0100 In-Reply-To: (Richard M. Stallman's message of "Sun, 30 Nov 2008 11:43:21 -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:106339 Archived-At: Hi Richard, Richard M Stallman writes: > The main issue about multiple threads in Emacs is, > when should a thread-switch be possible? I think it should > be allowed only where quitting is allowed. Otherwise, > internal data can be made inconsistent. > > Does pthreads provide the option to forbid thread-switching except > when the code calls a specific function? If so, we could make the > QUIT macro run that function if there is more than one thread. Internal data shared among threads must be accessed only inside critical sections in the .c code to have atomic operations on it. The elisp programmer must not care about what other threads are doing and using the shared data, only the thread local data is guaranteed to be accessed only by a thread. It may seem a limitation but it will allow us a real parallelism with different threads executed at the same time, in this way we can take advantage of modern multi-cores machines. > (create-thread) > (with-thread id '(code)) > (kill-thread id) > > It seems to me that `with-thread' should be renamed to > `run-in-thread'. Meanwhile, `with-thread' should be a macro that > creates a new thread, starts running the body code in it, and will > kill it when that body code finishes. > > It is un-Lispy to represent threads with numbers. They should be > represented by objects that contain info about them. If there is a > table of threads, it should not have a fixed size -- it should be > extended with realloc whenever it gets full. Right, I used numbers to represent threads (and many other simplifications) to have quickly something working and understand what later can be a problem. > What should happen when another thread gets an error? Should Emacs > run the debugger in that thread? (Probably rather annoying.) Kill > the thread? Leave the thread somehow suspended to be examined (but > how?). Kill the thread, and leave some info about the error in the > dead thread object? Perhaps there should be a way to specify a choice > for each thread. I would avoid something magic and kill the thread. What do you think about running the debugger without interrupting the execution of other threads? If another thread will get an error then another debugger is executed in a new buffer. Potentially every thread can cause the execution of a debugger in a new buffer and have the possibility to be investigated separately from others. > It should not be hard to find all the existing threads and mark all > their stacks and specpdls. I like the Stefan's idea of stopping all running threads while the GC is executed, in this way we can use the current GC without big changes. At least until a concurrent [parallel] GC will be alive. Regards, Giuseppe