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: Patch for fields of `struct buffer' Date: Tue, 01 Feb 2011 10:43:09 -0500 Message-ID: References: <4D46E75E.7080503@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1296575003 20162 80.91.229.12 (1 Feb 2011 15:43:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 15:43:23 +0000 (UTC) Cc: emacs-devel@gnu.org, David De La Harpe Golden To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 16:43:18 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 1PkINx-0005F6-Sn for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 16:43:18 +0100 Original-Received: from localhost ([127.0.0.1]:55262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkINx-0002rm-FS for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 10:43:17 -0500 Original-Received: from [140.186.70.92] (port=36864 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkINs-0002rY-VY for emacs-devel@gnu.org; Tue, 01 Feb 2011 10:43:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkINr-0007nW-Rv for emacs-devel@gnu.org; Tue, 01 Feb 2011 10:43:12 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:23399 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkINr-0007nM-Ok for emacs-devel@gnu.org; Tue, 01 Feb 2011 10:43:11 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANO4R01Ld/8K/2dsb2JhbAClBXS8ToVTBIUTj2Q X-IronPort-AV: E=Sophos;i="4.60,410,1291611600"; d="scan'208";a="90116155" Original-Received: from 75-119-255-10.dsl.teksavvy.com (HELO ceviche.home) ([75.119.255.10]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 01 Feb 2011 10:43:10 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 95751660DC; Tue, 1 Feb 2011 10:43:09 -0500 (EST) In-Reply-To: (Tom Tromey's message of "Mon, 31 Jan 2011 12:04:07 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:135403 Archived-At: > Other ideas I have been considering: > Instead of explicit locks, just let any symbol function as a lock, and > have the locks hidden in the C code. (Or an extension of this idea, let > any Lisp object be a lock -- "Java style".) As we discussed in the past, the first step is of course cooperative threading, via context switches at I/O points, which is a "minor" tweak to the current semantics (where we already have such switches but the threads are nested, i.e. the main thread can only re-start once the sub-thread (a process filter or sentinel) finishes). If/when we'll get to finer grained concurrency, I think it makes sense to use something that's as clean and high-level as possible: Elisp is already slow and interpreted, so we can afford something "slow". > Or, instead of the locks-and-condition-variables approach, go the CSP > route and have channels and channel-select. This idea is making a > comeback, maybe it would fit well in Emacs Lisp. Erlang-style concurrency is nice and clean, but I'm not sure it'll integrate well with existing code which stomps over a global state all the time. This doesn't mean it won't work. If we can make it work something like "one agent per buffer" and turn `set-buffer' into a kind of message maybe we could get some good results, but it seems tricky. Threads and locks don't look too good: too low-level. If we go in that direction, then STM seems a lot more appealing. Stefan