From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Elisp containers Date: Fri, 07 Sep 2018 14:13:53 -0600 Message-ID: <871sa5xdz2.fsf@tromey.com> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1536351214 18352 195.159.176.226 (7 Sep 2018 20:13:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Sep 2018 20:13:34 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 07 22:13:30 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fyN8E-0004gl-I7 for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 22:13:30 +0200 Original-Received: from localhost ([::1]:40121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyNAK-00042q-NU for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 16:15:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyN9f-00042V-3S for emacs-devel@gnu.org; Fri, 07 Sep 2018 16:15:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyN9b-0001LH-Lc for emacs-devel@gnu.org; Fri, 07 Sep 2018 16:14:59 -0400 Original-Received: from gateway33.websitewelcome.com ([192.185.145.9]:14302) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fyN9b-0001J5-8m for emacs-devel@gnu.org; Fri, 07 Sep 2018 16:14:55 -0400 Original-Received: from cm15.websitewelcome.com (cm15.websitewelcome.com [100.42.49.9]) by gateway33.websitewelcome.com (Postfix) with ESMTP id F3D431F89A for ; Fri, 7 Sep 2018 15:14:53 -0500 (CDT) Original-Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id yN8cftySlbXuJyN9CfDlU9; Fri, 07 Sep 2018 15:14:53 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WoBRpoCFyXyc6jw4dtuT0KGLlpO01GoELmmaNTWTrUQ=; b=MtjaBZpPfLLFKxZ9i990M7A6hq atGBMsHieTDaWLgvqgKush9RtV69W0kwkOtq8KCMviJpzVqnn9KUeRAyHEc1m02aLv2oI1H2IKUqG 4F3wO0j8EoayNR4/3bXAW1hfE; Original-Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:50862 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fyN8c-001X9Q-NI; Fri, 07 Sep 2018 15:13:54 -0500 X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Fri, 07 Sep 2018 10:38:18 -0400") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.85.72 X-Source-L: No X-Exim-ID: 1fyN8c-001X9Q-NI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-85-72.hlrn.qwest.net (pokyo) [75.166.85.72]:50862 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 192.185.145.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229449 Archived-At: >>>>> "Stefan" == Stefan Monnier writes: Stefan> If someone feels like they have too much time on their hands, I think Stefan> a great feature to develop would be Elisp containers. Stefan> This would be like running Elisp in a separate process, except that it's Stefan> not a separate process, so communication between two containers can be Stefan> very efficient (e.g. you can send a buffer from one container to the Stefan> other as efficiently as you can send an integer). I considered this when working on threads. I thought I'd write to discuss the problems I had with it; not to discourage anybody, but in case somebody has thoughts on how to improve things. I think the basic idea is to avoid data races while also avoiding the overhead of a separate process. So the design should keep things in process (duh) and also reject shared mutable state; instead objects must be explicitly sent between threads. (If you lift this latter requirement then you really just have what we have now.) So, first, what environment should a new thread inherit? If it is a clean environment -- say a copy of the dumped state -- then that means that user changes won't affect threads. And, threading code will need to know exactly what things must be copied into the new container. This seemed unfortunate to me, not to mention hard on thread users, because it's difficult in an open environment to know what may be required. (You can see echoes of this problem in the mhtml mode, where it has to use a regexp on symbol names, eww, to capture locals.) However, if it is not a clean environment, then thread creation will be very expensive. You will have to copy much of the heap into the new thread. (Perhaps the copying could be done lazily at the expense of slowing down access to global variables.) Second, sending a large object to another thread will also be slow. The buffer *itself* is not too bad, but buffers have properties and buffer-local bindings, and these must all be deep copied. One idea I had to reduce the cost here was to have a special case: when a thread dies, let thread-join simply transfer the data from that thread to its own heap. Finally, this approach greatly reduces debuggability and the ability to mess around. Emacs would no longer be an open system -- threads would have private data and there would be no way to access that. Tom