From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Tue, 01 Feb 2011 09:51:54 -0700 Message-ID: References: <4D47DFD4.1040108@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296589878 11187 80.91.229.12 (1 Feb 2011 19:51:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 19:51:18 +0000 (UTC) Cc: Daniel Colascione , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 20:51:13 2011 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.69) (envelope-from ) id 1PkMFs-0004xK-Tl for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 20:51:13 +0100 Original-Received: from localhost ([127.0.0.1]:47517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkMFs-0001MG-Ch for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 14:51:12 -0500 Original-Received: from [140.186.70.92] (port=41140 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkJSb-0000N0-5A for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:52:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkJSX-0007on-15 for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:52:08 -0500 Original-Received: from mx1.redhat.com ([209.132.183.28]:7341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkJSQ-0007jn-Fy; Tue, 01 Feb 2011 11:51:58 -0500 Original-Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p11GpuGO021638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 11:51:56 -0500 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p11Gptpb001909; Tue, 1 Feb 2011 11:51:55 -0500 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p11GpsRX016635; Tue, 1 Feb 2011 11:51:55 -0500 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id B2C77378301; Tue, 1 Feb 2011 09:51:54 -0700 (MST) X-Attribution: Tom In-Reply-To: (Richard Stallman's message of "Tue, 01 Feb 2011 11:41:02 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 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:135422 Archived-At: RMS> Your argument makes sense, for people using powerful machines. RMS> I have a slow one, by today's standards, and I don't think it is RMS> likely I will get a faster one (or multicore) for years if ever. RMS> Many free software activists use the same machine for the same reason. It is an empirical question as to whether this change slows things down too much. I don't think it is the case that any slowdown is unacceptable. One thing worth noting is that if the concurrency branch is a huge failure, it is simple to back out at least the buffer change. It can be done with a perl one liner. And, since there is no performance penalty possible until concurrency is actually merged, I think the risks associated with moving forward are rather low. RMS> Meanwhile, the big problem of making Emacs work with true parallelism RMS> is not in the general mechanisms. It is in all the code that knows RMS> it can only be interrupted due to an error or where it says QUIT. RMS> If you want to test the feasibility of real parallelism, that's what RMS> you need to work on. The point of this patch series is to make it simpler to work on the other problems on a branch. Without the infrastructure in place, merging (in either direction) is simply too difficult. That is, it is a stepping stone to getting cooperative threading, which itself is a stepping stone to real parallelism. Tom