From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Nic Ferrier Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 30 Nov 2003 19:40:39 +0000 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87vfp17ih4.fsf@kanga.tapsellferrier.co.uk> References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <87ekvpx18d.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070221635 4739 80.91.224.253 (30 Nov 2003 19:47:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2003 19:47:15 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Nov 30 20:47:12 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQXXE-0001w2-00 for ; Sun, 30 Nov 2003 20:47:12 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQXXE-0006UU-00 for ; Sun, 30 Nov 2003 20:47:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AQYQL-0007Kw-EE for emacs-devel@quimby.gnus.org; Sun, 30 Nov 2003 15:44:09 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AQYQ2-0007KT-Qk for emacs-devel@gnu.org; Sun, 30 Nov 2003 15:43:50 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AQYPW-00077i-Oj for emacs-devel@gnu.org; Sun, 30 Nov 2003 15:43:49 -0500 Original-Received: from [80.168.153.201] (helo=tf1.tapsellferrier.co.uk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AQYPS-0006zX-FA for emacs-devel@gnu.org; Sun, 30 Nov 2003 15:43:14 -0500 Original-Received: from [80.168.156.74] (helo=kanga.tapsellferrier.co.uk) by tf1.tapsellferrier.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1AQXR0-0007UN-00; Sun, 30 Nov 2003 19:40:46 +0000 Original-Received: from localhost ([127.0.0.1] helo=kanga.tapsellferrier.co.uk ident=nferrier) by kanga.tapsellferrier.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 1AQXQt-0003VK-00; Sun, 30 Nov 2003 19:40:39 +0000 Original-To: Kai Grossjohann In-Reply-To: <87ekvpx18d.fsf@emptyhost.emptydomain.de> Original-Lines: 39 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18227 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18227 Kai Grossjohann writes: > Miles Bader writes: > > > Consider a simple bit of elisp code: (setq GLOBAL (cons 'x GLOBAL)) > > In a pre-emptively threaded emacs, another thread could run between > > accessing GLOBAL and setting it. Whoops. > > Well, I don't know a lot about threading, but Java, at least, has the > same problem: you need to synchronize access to a variable to prevent > such things from happening. By default, synchronized access is turned > off. > > So if all of what is now in Emacs continues to run in a single thread, > and you just provide a function to create a new thread and run stuff > in that new thread, then it would be the responsibility of the people > creating threads to make sure that they don't step on each other's > toes. > > Then the remaining problem is that possibly a lot of functions cannot > be safely used because they access global variables. But that is just > something that people will have to live with, and maybe it will get > better over time. I think that it will be good enough at least for > some packages to do part of their work in the background. > > What do people think? Maybe I missed something obvious... I think there are 2 big problems: 1. emacs _is_ global variables, there aren't any thread safe routines right now because thread safety has not been an issue uptil now. So display, buffer manipulation, everything becomes a thread problem. 2. I think dynamic scope also makes this a lot more complicated because you're not talking about just globals anymore but variables passed from a proc into a thread-proc and onwards. Very tricky. Nic