From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: multi-threaded Emacs Date: Sun, 30 Nov 2008 22:55:47 -0500 Message-ID: References: <87abbiody1.fsf@master.homenet> <877i6l5d8s.fsf@master.homenet> <87prkcetze.fsf@catnip.gol.com> <87abbg7qvj.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 1228103770 3600 80.91.229.12 (1 Dec 2008 03:56:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2008 03:56:10 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, Miles Bader To: Giuseppe Scrivano Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 04:57:14 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 1L6zuK-0002Nf-IR for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2008 04:57:12 +0100 Original-Received: from localhost ([127.0.0.1]:34376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6ztA-0007Fq-E9 for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2008 22:56:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6zt5-0007Fk-EN for emacs-devel@gnu.org; Sun, 30 Nov 2008 22:55:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6zt2-0007FX-VK for emacs-devel@gnu.org; Sun, 30 Nov 2008 22:55:54 -0500 Original-Received: from [199.232.76.173] (port=43539 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6zt2-0007FU-SG for emacs-devel@gnu.org; Sun, 30 Nov 2008 22:55:52 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:43473) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6zsy-0000Mm-O5; Sun, 30 Nov 2008 22:55:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgEAFvvMknO+Jkl/2dsb2JhbACBbctHgn2BJA X-IronPort-AV: E=Sophos;i="4.33,692,1220241600"; d="scan'208";a="30458333" Original-Received: from 206-248-153-37.dsl.teksavvy.com (HELO pastel.home) ([206.248.153.37]) by ironport2-out.teksavvy.com with ESMTP; 30 Nov 2008 22:55:48 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A9ADC848A; Sun, 30 Nov 2008 22:55:47 -0500 (EST) In-Reply-To: <87abbg7qvj.fsf@master.homenet> (Giuseppe Scrivano's message of "Mon, 01 Dec 2008 00:09:36 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:106355 Archived-At: > Anyway, a non-preemptive threading will not give any real parallelism I admire your enthusiasm, but I think that if you don't want to get burned, you should set yourself more realistic goals. Parallelism is going to require a very large amount of work. We'll hopefully get there at some point, but there are many useful steps to have to take before we get there. > 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. Actually no. There are already `yield' points in Elisp: basically whenever we wait for a process or wait for user input. So there's no need to change too many things before we can start using cooperative threading (another name for "a single thread active at a time"). It's still useful because it introduces the multiple stacks, which will allow for example using one thread per terminal, so that doing M-x in one terminal will not screw over the other terminals. Also it'll make asynchronous execution easier. So it'll be useful to Elisp packages. It'll also be a useful implementation step on the way to parallelism, since it will make us deal with multiple stacks, dynamic scoping, ... We will already be able to try to tackle things like: be able to edit a file in a window while Gnus is waiting for your newsserver to send the list of new groups. Then we can think of making concurrency more fine-grained to try and get parallelism. > accesses with a lock/unlock, but how many times does it happen to change > the value of a global variable? *All* the time. Elisp is really terrible in this respect. Remember: all buffers are part of the "global state", same for pretty much all objects. Currently even "local variables" are actually global, tho admittedly, fixing dynamic-scoping will/should improve this part. Stefan