From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Thu, 6 Jul 2023 14:35:35 -0400 Message-ID: References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.fsf@localhost> <83pm57k01f.fsf@gnu.org> <87v8ey8uv7.fsf@localhost> <83bkgqk28a.fsf@gnu.org> <87mt0a8rak.fsf@localhost> <87h6qi8pxe.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22252"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 06 20:36:50 2023 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 1qHTqU-0005aM-2D for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jul 2023 20:36:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHTpZ-0005xV-DR; Thu, 06 Jul 2023 14:35:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHTpW-0005x6-T5 for emacs-devel@gnu.org; Thu, 06 Jul 2023 14:35:50 -0400 Original-Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHTpV-0004wC-1d; Thu, 06 Jul 2023 14:35:50 -0400 Original-Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-1a28de15c8aso1049102fac.2; Thu, 06 Jul 2023 11:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688668547; x=1691260547; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZwqgLeHFpSDa2qBey/xO1cOcfMIipz1lNfi620eCgZc=; b=sLgN6eo21vTul6f0t90qm7GV1WmYDoFsA11HL4nbuPVO4V5tPZMUIx+a1fs7eQft34 7jC98DS5Emtra0tqSkvxp5wygb0ORsZ0aIUd/YFWsfvW/ZJumqLYkQVDroGsyLJKIXaL 3t1gi2rOW8oAOYa8IJLxGSQ8g2SAcROFME9zUo7tvLkUhWFw7bl5oaPN9PkwXeN4rFDx n7Q6uQTRKqYk3q452mS4wEGl8Hczd+Y1/c3BZnFBE/LY3ko0kyiPkhXGZDuQzXEwNz05 voKVeE3OH2Kh2TiF9zKgeHGo3LkE8rjBetVF2MnyRoMrdb9/CdOsCMzqYCQw208jVnI/ ZiXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688668547; x=1691260547; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZwqgLeHFpSDa2qBey/xO1cOcfMIipz1lNfi620eCgZc=; b=C7SuW1R1B3T23psxdSsCdL3PCmuNyRWEqOv8WXRHhPBXMWPRwkn0n4HWgwNHA7hCBI bLq9EeAcIRMDA80A1hk7cxdnlyvlFPU1xaeZipu3/rtFdIbwDWbvCrwVFKPaGSQ2DoaB j6j6xo81rLBGTyPwl7UW3sTe/B7xCXxsydWitdJSvRIb1s9QwRbdrmUOejBIk5KNt3eI tzzjaALzuzvoSIOtAHrwkAii9N440k1KzC6u3wiQnhHDKM8mQmjfSgg/+mFlqVHbrJV/ uWCEKvKhMXvhlNdA5g4ACEhhbXh+MTgtJctrQi1s0sWj7Lm/qHoWPBVkIx1RUUAOI/wv PwoQ== X-Gm-Message-State: ABy/qLYJT6cAQaUQJwkutClf0D8rHjpod4kGQMpMIkMorWQ1EeJfPzoc ZU1Zgg/x1Viwv7uBMwVVBA/eLjwM+9Zdk16cqnw= X-Google-Smtp-Source: APBJJlFIBVlMn5s32u4QIexf0nvhKsMkCa4BodLtGf/hUl7CW2+3Id44uAlXlycCGdEiZYt4CFrmaz7OVBkuGL1R/rI= X-Received: by 2002:a05:6870:d626:b0:18e:af01:ad93 with SMTP id a38-20020a056870d62600b0018eaf01ad93mr3946044oaq.58.1688668546726; Thu, 06 Jul 2023 11:35:46 -0700 (PDT) In-Reply-To: <87h6qi8pxe.fsf@localhost> Received-SPF: pass client-ip=2001:4860:4864:20::2c; envelope-from=owinebar@gmail.com; helo=mail-oa1-x2c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307529 Archived-At: On Wed, Jul 5, 2023 at 9:10=E2=80=AFAM Ihor Radchenko = wrote: > > Lynn Winebarger writes: > > > The best idea I've had for a general solution would be to make "concurr= ent" > > versions of the fundamental lisp objects that act like immutable git > > repositories, with the traditional versions of the objects acting as > > working copies but only recording changes. Then each checked out copy > > could push charges back, and if the merge fails an exception would be > > thrown in the thread of that working copy which the elisp code could de= cide > > how to handle. That would work for inter-process shared memory or plai= n > > in-process memory between threads. Then locks are only needed for upda= ting > > the main reference to the concurrent object. > > Honestly, it sounds overengineered. > Even if not, it is probably easier to implement a more limited version > first and only then think about fancier staff like you described (not > that I understand your idea fully). > Maybe - I'm not claiming it's trivial. I do think the locking for that kind of design is generally much simpler and less prone to deadlocks than trying to make operations on the current set of fundamental objects individually atomic. Given how many lisp objects, e.g. buffers and functions, are referenceable by name through global tables, it's difficult to see how emacs could ever have fine-grained parallelism that's efficient, correct, and deadlock-free any other way. The inspiration for this approach (for me) was from reviewing the version control section of the emacs manual on approaches to concurrent access. Version control systems like git are essentially "concurrent editing in the large". What is required for emacs is "concurrent editing in the small", but the issues with sharing and updating are very much the same. Lynn