From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Questions about throw-on-input Date: Thu, 14 May 2020 23:54:09 -0400 Message-ID: References: <8920fe6a-8fe4-addd-c29e-2213850bf974@web.de> <83k11f7v4q.fsf@gnu.org> <4506133a-5e63-4ae7-9b5d-830359e8b673@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86177"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, p.stephani2@gmail.com, yyoncho@gmail.com, alexanderm@web.de, eliz@gnu.org, Drew Adams To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 15 05:55:13 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZRRI-000MKy-Ud for ged-emacs-devel@m.gmane-mx.org; Fri, 15 May 2020 05:55:12 +0200 Original-Received: from localhost ([::1]:40572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZRRI-0000kt-0c for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 23:55:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZRQN-0008R5-Nc for emacs-devel@gnu.org; Thu, 14 May 2020 23:54:15 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55847) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZRQM-0001Vv-Hb; Thu, 14 May 2020 23:54:15 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AC64710031E; Thu, 14 May 2020 23:54:12 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F2B521002CF; Thu, 14 May 2020 23:54:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1589514851; bh=iGePpVQdhVCg81tj4Tm2qiTfFZiOFid1NAecFQ3GvC4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DyzjR6Dum8W0fNl+cegnrtf/bX5WwHlo4LolEA/lLOVuMipAAvcRVvxEHONPXx3TO qXAtKlYRh9/aJBKWx+jlhtOUKOIZh0q8GsBY386XQrISjamPM5HPSE3l47qOozuaoM 5HZbp/dnSVWtdzMcet5v+yBbKs5AQ0r3drMxeQhHM0GG3nNQoOWfAsl+TN3xzSuSs5 ujfFWFUGdPZNTbt6dc8ASnNFwZ1x8zEMQxkrUR9hyvauICmzr73IUjTeb5E51P9WnI WkQh8aWt5L3jpF23ZoJH9OjhRu7xhAnHkCsR19Xz8M3o6DpTApQ1FGeQosTK5/vg3G FyuxT5L+ONJRg== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 86FCA1204A1; Thu, 14 May 2020 23:54:10 -0400 (EDT) In-Reply-To: (Richard Stallman's message of "Thu, 14 May 2020 23:21:29 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/14 23:42:00 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250337 Archived-At: > An editor buffer is global mutable state. Global mutable state is at > the heart of GNU Emacs, and I disagree with the idea that we should > try to get away from it. That is a non-goal. But the goal talked about here is concurrency. Concurrency is not incompatible with global state, but it's incompatible with global state accessed from anywhere without any way to control it. The problem, as I see it, is that we could imagine binding threads to buffers such that a buffer can only be accessed by a single thread at a time. That would be reasonably easy to implement, I think, by putting a lock on buffer objects (since there are fairly few ways to access a buffer: you almost always have to make it current first). But the buffer's local variables can contain data such as hash-tables or cons-cells which can be shared between various buffers, and that is a lot harder to control because we don't want to put a lock on every cons cell. Maybe we could have a notion of "buffer-local data/heap" and "global read-only data/heap" or something like that and some way make sure that a thread only operates of buffer-local data and global read-only data, in which case it can indeed safely run concurrently with other Elisp code operating in other buffers. Stefan