From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Tue, 01 Feb 2011 11:40:19 -0500 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: dough.gmane.org 1296579996 17715 80.91.229.12 (1 Feb 2011 17:06:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 17:06:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 18:06:32 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 1PkJgS-0007a6-40 for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 18:06:32 +0100 Original-Received: from localhost ([127.0.0.1]:45747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkJHT-0007Qp-75 for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 11:40:39 -0500 Original-Received: from [140.186.70.92] (port=54034 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkJHF-0006Pp-NZ for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:40:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkJHD-0003d4-Ii for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:40:24 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:49081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkJHD-0003d0-G6 for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:40:23 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PkJH9-0007ZX-6y; Tue, 01 Feb 2011 11:40:19 -0500 In-reply-to: (message from Tom Tromey on Mon, 31 Jan 2011 12:57:52 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:135410 Archived-At: RMS> Are you saying you would like to change it so that every access to RMS> a Lisp variable requires indirecting? Only potentially -- like today. That is not a problem, then. For each global variable, the per-thread pointer will ordinarily point to the main thread's slot. When the variable is let-bound, thus becoming thread-local, the pointer will be redirected to the slot in the per-thread structure. When the outermost let-binding is undone, the pointer will be reset to the main thread's slot. This seems to give the right semantics, but having a pointer in each thread for each DEFVAR_LISP variable makes threads rather heavy. How many such variables are there now? I'd expect thousands. -- Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org