From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Threads in emacs implementation Date: Fri, 17 Jun 2005 10:09:38 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <4nzmtpqdlp.fsf@lifelogs.com> References: <6dbd4d0005060619227dd41364@mail.gmail.com> <87vf4oaft8.fsf@zemdatav.stor.no-ip.org> <4nd5quav0o.fsf@lifelogs.com> <4nll5btxv7.fsf@lifelogs.com> <4nvf4eqnec.fsf@lifelogs.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1119017949 8487 80.91.229.2 (17 Jun 2005 14:19:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Jun 2005 14:19:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 17 16:19:08 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DjHg2-0001qh-9m for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2005 16:18:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DjHlf-0003Pn-0z for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2005 10:24:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DjHlP-0003My-P7 for emacs-devel@gnu.org; Fri, 17 Jun 2005 10:24:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DjHlM-0003MD-FV for emacs-devel@gnu.org; Fri, 17 Jun 2005 10:24:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DjHhh-0002Jv-JA for emacs-devel@gnu.org; Fri, 17 Jun 2005 10:20:17 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DjHaN-0006pM-Fz for emacs-devel@gnu.org; Fri, 17 Jun 2005 10:12:44 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DjHSc-0007Fh-44 for emacs-devel@gnu.org; Fri, 17 Jun 2005 16:04:42 +0200 Original-Received: from asimov.bwh.harvard.edu ([134.174.8.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Jun 2005 16:04:42 +0200 Original-Received: from tzz by asimov.bwh.harvard.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Jun 2005 16:04:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 27 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: asimov.bwh.harvard.edu X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:cA4y23aTgaBI3qaVThaPWZmwfIM= 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:39022 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39022 On Fri, 17 Jun 2005, snogglethorpe@gmail.com wrote: > A huge amount of the actively maintained state in Emacs is stored in > global variables (often buffer-local of course, but still "global" > as far as threads are concerned). Thank you for the clarification. I'm thinking of ways to avoid the stack penalties the other proposals involve. Could we allow only secondary threads with thread-local variables and forked copies of globals? Then, to modify the main thread's version of a global variable a special protocol must be followed (through the VM). Threads wouldn't be able to access existing buffers and buffer-local variables without going through the VM protocol, either (but they can create their own buffers, which will be isolated within the thread). The ideal thread would be a pure function (if I remember my definitions right, a pure function f(x) depends only on x). This will make threads more of a utility than a true built-in, and threaded code would be written especially for that purpose. Existing code would continue to run without changes - this will save us rewriting a huge amount of code. Is this feasible? Would this kind of limited threading be useful? Ted