From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Mon, 07 Feb 2011 09:05:30 +0100 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 1297065982 6709 80.91.229.12 (7 Feb 2011 08:06:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 08:06:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 07 09:06:15 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 1PmM6x-0002Sl-5a for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 09:06:15 +0100 Original-Received: from localhost ([127.0.0.1]:49337 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmM6w-0000zm-H4 for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 03:06:14 -0500 Original-Received: from [140.186.70.92] (port=43629 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmM6i-0000z8-BN for emacs-devel@gnu.org; Mon, 07 Feb 2011 03:06:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmM6g-0002bI-Vq for emacs-devel@gnu.org; Mon, 07 Feb 2011 03:06:00 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:53683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmM6g-0002b6-G2 for emacs-devel@gnu.org; Mon, 07 Feb 2011 03:05:58 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PmM6a-0002LH-1u for emacs-devel@gnu.org; Mon, 07 Feb 2011 09:05:52 +0100 Original-Received: from dial-176241.pool.broadband44.net ([212.46.176.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Feb 2011 09:05:51 +0100 Original-Received: from eller.helmut by dial-176241.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Feb 2011 09:05:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176241.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:H6feLHpXSlzY94DFdViBx/tnZX4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:135670 Archived-At: * Tom Tromey [2011-02-07 02:44] writes: >>>>>> "Stefan" == Stefan Monnier writes: > > Stefan> Erlang-style concurrency is nice and clean, but I'm not sure it'll > Stefan> integrate well with existing code which stomps over a global state all > Stefan> the time. This doesn't mean it won't work. If we can make it work > Stefan> something like "one agent per buffer" and turn `set-buffer' into a kind > Stefan> of message maybe we could get some good results, but it seems tricky. > > I couldn't think of a way to make this work, at least not with > `set-buffer' as the primitive. How does a thread get the buffer in the first place? In an Erlang-style model a thread either has to create the buffer or receive it as a message from an other thread. Message passing could do some magic to pass ownership: the receiver is the new owner of the buffer and the sender loses ownership. set-buffer would then check that the current thread is the owner. As a refinement we could have something like "read-capability" and "write-capability". Capabilities are also passed with message passing. A thread that has write-capability can modify the buffer as usual. Threads with read-capability can read the buffer but this kind of reading--especially buffer properties or buffer local variables--needs to copy the value (sometimes) to avoid sharing state. Does that sound too complicated? > I think it could be done by having all other buffer-manipulating > primitives (e.g., `insert') work by message-passing to some other > thread. This is basically like a buffer lock. Well, no mutable objects could be shared, which is quite different from a lock; especially the case when somebody forgets to use the lock. > I am interested in reasoned arguments, grounded in real Emacs code, to > the contrary for either STM or CSP. With some hand-waving, the current way to deal with external processes can be seen as form of CSP. Otherwise I'd say current Emacs code neither uses STM nor CSP nor locks, which makes it hard to meet your request. Helmut