From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lynbech Christian Newsgroups: gmane.emacs.devel Subject: Re: advice needed for multi-threading patch Date: Mon, 28 Sep 2009 09:44:11 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: ger.gmane.org 1254123908 16247 80.91.229.12 (28 Sep 2009 07:45:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2009 07:45:08 +0000 (UTC) Cc: Tom Tromey , Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 09:45:01 2009 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 1MsAup-0006UN-UD for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 09:45:00 +0200 Original-Received: from localhost ([127.0.0.1]:53572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsAup-00076U-DY for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 03:44:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsAuJ-0006lJ-L8 for emacs-devel@gnu.org; Mon, 28 Sep 2009 03:44:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsAuD-0006jQ-LM for emacs-devel@gnu.org; Mon, 28 Sep 2009 03:44:27 -0400 Original-Received: from [199.232.76.173] (port=48432 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsAuD-0006jK-H6 for emacs-devel@gnu.org; Mon, 28 Sep 2009 03:44:21 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:4076) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MsAuD-0004l3-0Q for emacs-devel@gnu.org; Mon, 28 Sep 2009 03:44:21 -0400 Original-Received: from ebb06.tieto.com ([131.207.168.38]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsAuA-0007Fb-53 for emacs-devel@gnu.org; Mon, 28 Sep 2009 03:44:18 -0400 X-AuditID: 83cfa826-a2857bb000000855-93-4ac0694f63f2 Original-Received: from FIVLA-EXHUB02.eu.tieto.com (unknown [131.207.136.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ebb06.tieto.com (SMTP Mailer) with ESMTP id 124E436A4A4; Mon, 28 Sep 2009 10:44:15 +0300 (EEST) Original-Received: from ul000205.eu.tieto.com (10.48.99.26) by inbound.tieto.com (131.207.136.49) with Microsoft SMTP Server id 8.2.176.0; Mon, 28 Sep 2009 10:44:08 +0300 In-Reply-To: (Stefan Monnier's message of "Tue, 22 Sep 2009 17:24:15 +0300") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) X-Brightmail-Tracker: AAAAARDv2Y0= X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:115715 Archived-At: >>>>> "Stefan" == Stefan Monnier writes: Stefan> Maybe another way to look at all these problems is to take an "agent" Stefan> point of view: rather than threads moving around, we could consider each Stefan> keyboard and each buffer as an active object (i.e. with its own thread), Stefan> which communicate among each other. I.e. a buffer-thread never leaves Stefan> its buffer, instead it does an RPC to another buffer-thread, or to Stefan> a keyboard-thread, ... This seems like a really clever idea, but I didn't see any response to it. Has anybody thought more about this? Everything in Emacs is centered around buffers anyway and I guess that a lot of the RPC (at least wrt. keyboards) would look a lot like the events comming in from X anyway. The biggest problem I see here is that you can have a large number of buffers. I do not know what the practical limit on the number of threads are on modern systems, but if that is a concern one could instead tie the threads to processes/filters/sentinels (which aren't really interactive anyway) and windows/frames which all user interaction goes through. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)