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: Tue, 08 Feb 2011 18:57:43 +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 1297187892 22618 80.91.229.12 (8 Feb 2011 17:58:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2011 17:58:12 +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 08 18:58:04 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 1PmrpE-0007mm-03 for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2011 18:58:04 +0100 Original-Received: from localhost ([127.0.0.1]:52456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmrpD-0004ul-6Q for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2011 12:58:03 -0500 Original-Received: from [140.186.70.92] (port=40843 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pmrp3-0004sh-5w for emacs-devel@gnu.org; Tue, 08 Feb 2011 12:57:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pmrp2-0006wG-4s for emacs-devel@gnu.org; Tue, 08 Feb 2011 12:57:53 -0500 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:58471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pmrp1-0006vu-WD for emacs-devel@gnu.org; Tue, 08 Feb 2011 12:57:52 -0500 Original-Received: by wyj26 with SMTP id 26so6339454wyj.0 for ; Tue, 08 Feb 2011 09:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=6N8/T/SUKy2izVMAUUyV6895138K7Ojh5HxZ2GSCrWw=; b=GQ9tQzurN736wfjUVbvx5Svh7L87ng+PdhHY6ltQxSOYMEaU1SSVlZIcxSkbfQDWPX GsTHCi5ZmCl8AgHdBnQcd70lTBXENmJTZ11tOYn3Csj1fHuxT+fr9/QLiZeAAyqB+gDf khrOWh64KG/ox29bDk52Y0HIt9de0fL+/gCfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=bEiY/3PzD6mtd0RpibGlbWPOdQo+Cmwy333JnqNLuy6MRRxZvH6pzh0OwzuDTRddFu 8apAE0dUlILlfRzOW1uwEAxkicrtJaJutErsuW4NK7cXTB721flZml04luX970KLkOBP gTKnSOKQU1c0JO05Zotl1nOECxZ0OODQSM6hI= Original-Received: by 10.227.156.21 with SMTP id u21mr12412461wbw.228.1297187869909; Tue, 08 Feb 2011 09:57:49 -0800 (PST) Original-Received: from ix (dial-176241.pool.broadband44.net [212.46.176.241]) by mx.google.com with ESMTPS id r6sm2982988weq.20.2011.02.08.09.57.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 09:57:48 -0800 (PST) Original-Received: from helmut by ix with local (Exim 4.72) (envelope-from ) id 1Pmroy-0001Mx-VT; Tue, 08 Feb 2011 18:57:49 +0100 In-Reply-To: (Tom Tromey's message of "Tue, 08 Feb 2011 09:26:09 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.169 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:135763 Archived-At: * Tom Tromey [2011-02-08 16:26] writes: >>>>>> "Helmut" == Helmut Eller writes: > > Helmut> Well, no mutable objects could be shared, which is quite different from > Helmut> a lock; especially the case when somebody forgets to use the lock. > > Tom> I am interested in reasoned arguments, grounded in real Emacs code, to > Tom> the contrary for either STM or CSP. > > Helmut> With some hand-waving, the current way to deal with external processes > Helmut> can be seen as form of CSP. Otherwise I'd say current Emacs code > Helmut> neither uses STM nor CSP nor locks, which makes it hard to meet your > Helmut> request. > > What I meant by this is that any proposed change has to come with a plan > to upgrade the existing body of Emacs Lisp code, not all of which is > included in Emacs. I think threads are a new feature and it wouldn't surprise me that new code must be written to use that feature. > With locks it is probably possible to do this piecemeal. I think explicit locks put the burden on the programmers. They must debug/update/fix their programs for a multi-threaded world even if they don't use threads. Not a pay-as-you-go kind of plan, is it? > I don't know how to do it for CSP, and for STM the C side seems much too > hard to contemplate. > > Likewise, I think sharing mutable objects is inevitable given the way > Emacs Lisp is already written. HTML5 Web Workers avoid shared mutable objects. Instead of creating a thread with (spawn (lambda () ...)) we would have something like (worker "task.el"). Where "task.el" is a file containing the program that does all the work. A worker starts with an (almost) empty environment and must initialize all needed state from zero. In particular if some library is needed it must be loaded explicitly (that's not visible in the parent thread). A worker can only communicate with other threads via pipes (I think workers exchange Javascript objects in JSON format in HTML5; maybe we would use sexps for Emacs). This is certainly more heavy weight and probably has its own set of problems but it obviously works without shared mutable state. Helmut