From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Fri, 07 Jul 2023 22:36:03 +0300 Message-ID: <83fs5zecpo.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.fsf@localhost> <878rbtkz2c.fsf@yahoo.com> <87a5w96x2o.fsf@localhost> <87jzvdjjp4.fsf@yahoo.com> <877crd6w53.fsf@localhost> <877crdjiwn.fsf@yahoo.com> <874jmh6v4s.fsf@localhost> <83y1jtgmbw.fsf@gnu.org> <87zg49xfke.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21709"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 07 21:36:51 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 1qHrG7-0005TF-0I for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jul 2023 21:36:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHrFP-0005wT-4I; Fri, 07 Jul 2023 15:36:07 -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 1qHrFK-0005ts-Gy for emacs-devel@gnu.org; Fri, 07 Jul 2023 15:36:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHrFJ-0003Or-Fx; Fri, 07 Jul 2023 15:36:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=kl0qvbbwzeXeyZkXJq6rx5fDctCtiKybWmHf5C5iVPM=; b=Vc4SfQ/e52gx Onw7nIEEBdxg1KCan1TGzkzew7tJEXyudrFQvjbzf3Y3TYmJfBR3A1n8iQXb/UO4ajiKGCaqnJTka 7GESkUCuoueF1C4e1U0sOWrJFokLFpXH0ch33oX4NtKywA6Cne3NhkTX4O1vCIS0dWbfOsVnRIn0o Aie9kfNEjSEefX/mtN/weugGSubLnb6NayHom67ZXUEmgUOPFDwmDaCaPni0WK8vPg7YuCytQV+K7 W6yrToei0skI3ePGHBnwbIXrRD1+LqxPwaJ8FOJ3VV2v0b02pk6kQ68rH+WjcmVJS8WA9QlzHIET9 dbTodq0IJsPk8m/Cc6SB3Q==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHrFI-000681-W7; Fri, 07 Jul 2023 15:36:01 -0400 In-Reply-To: <878rbrbmwr.fsf@localhost> (message from Ihor Radchenko on Fri, 07 Jul 2023 18:24:04 +0000) 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:307586 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Fri, 07 Jul 2023 18:24:04 +0000 > > Eli Zaretskii writes: > > >> May you please provide a concrete example how running GC breaks things? > > > > I already did: see my description of compacting strings, relocating > > buffer text, and other stuff GC does. > > But how exactly does, say, relocating buffer text can break things? May > you provide a pseudo-code example? If by "lock the buffer" you mean that buffer text cannot be relocated, then you hurt GC and eventually the Emacs memory footprint. If you consider allowing relocation when the buffer is locked, then some of the threads will be surprised when they try to resume accessing the buffer text. > >> I am interested in specific details. The way you say it now is general > >> and sounds like "it is impossible and there is no point trying to do > >> anything". > > > > That's indeed what I want to say. You cannot have true concurrency as > > long as Emacs Lisp programs use this huge global state. > > Then the question is: can the global state be reduced? By what measures? Please suggest something concrete here. > May it be acceptable to have a limited concurrency where async threads > are only allowed to modify a portion of the global state? I don't see how one can write a useful Lisp program with such restrictions.