From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Gap buffer problem? Date: Thu, 12 Dec 2024 00:07:16 +0200 Message-ID: References: <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.fsf@gnu.org> <87v7vqjexy.fsf@protonmail.com> <86cyhy2g97.fsf@gnu.org> <87ldwmj8sw.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4744"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org, ofv@wanadoo.es To: Pip Cet , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 23:08:21 2024 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 1tLUsW-00013l-9p for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 23:08:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLUrf-0001CD-Ph; Wed, 11 Dec 2024 17:07:27 -0500 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 1tLUre-0001Bt-1c for emacs-devel@gnu.org; Wed, 11 Dec 2024 17:07:26 -0500 Original-Received: from fhigh-a6-smtp.messagingengine.com ([103.168.172.157]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLUra-0001Oc-9u; Wed, 11 Dec 2024 17:07:25 -0500 Original-Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9603E11401ED; Wed, 11 Dec 2024 17:07:20 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Wed, 11 Dec 2024 17:07:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1733954840; x=1734041240; bh=OglfsFUCiqzFbrhglPngcGcw5k3qNLtVAvR8VqeYcJ4=; b= V+59EN5VCEFfoTH1NJJu+wFR7vsSYDdRvGvm0TGZtKuhBTNEamadBvOn0akzmlzk dns2epFzLiJrMmiHDt9OV0CE728sdcjxgVYFV0lGiqww3pH8fyclUc91FcbTXhkV ACREtEt0U2GiTXir9PAvJ04cVAuzxRfRCdWdjXdEEiBK+A9hohRo8+F28tdnjEuq q3i3wIy22Gb3EmtSbIBMOJ1fZaP4SMTyPWrEhFj4MKMA7x9fStkW6HwMWuIHKFAI SFMJLiQlHtsAgN7ftaPk6XlY1QINvabdgIxQvpKwYY6a4nEfh1Uk9tHM3We7w003 hKms/uVwo3p1l3xePqvFpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1733954840; x= 1734041240; bh=OglfsFUCiqzFbrhglPngcGcw5k3qNLtVAvR8VqeYcJ4=; b=l 3yKquCIL6ML8FRXRksSW6yQs7FRfc1lgCCgSCE5lNXpRiIty4M56invVL+Nj3rz0 MQUi0DtcJiiwjBhiPt/ORY/5/PjUEs4oGpcEWZd9+HmEdDcFhRCYLSTzEX2dXvGd wCAW6AVCDpE6JACs91sc3v6nfTJAlx6MCunEJhuIq40pJ2EXoaUGb9NeZwQyKqeN mcL94jbznNKVcTmsh99Rxkt8zx8lu8E3rnNwX1vkkJEeKpLkWjw09xGSCOJyMGjE B2UgjCxg9phGhRtRmd3cWpvnfcCxhVkJVYRgQ2RxaS7VQSvyB4WIbOvw2mAKcG0t vZ1Y9X5mkSPts+5qLEBqA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkedtgdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehpihhptggvthesphhrohhtoh hnmhgrihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthht ohepghgvrhgurdhmohgvlhhlmhgrnhhnsehgmhgrihhlrdgtohhmpdhrtghpthhtohepvg hmrggtshdquggvvhgvlhesghhnuhdrohhrghdprhgtphhtthhopehofhhvseifrghnrggu ohhordgvsh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 Dec 2024 17:07:18 -0500 (EST) Content-Language: en-US In-Reply-To: <87ldwmj8sw.fsf@protonmail.com> Received-SPF: pass client-ip=103.168.172.157; envelope-from=dmitry@gutov.dev; helo=fhigh-a6-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1 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:326384 Archived-At: On 11/12/2024 21:54, Pip Cet via Emacs development discussions. wrote: > It is very different indeed: > > Copying within a process involves changing the (virtual) addresses that > the copied data is at (unless you use an architecture-specific > implementation of TLS). The beauty of fork() is that the virtual > addresses stay the same, so we don't need to adjust any pointers, which > we cannot do because there are ambiguous references to Lisp data. > > IOW, no, you can't lazily create two copies of Lisp data in the same > process. You have to do so eagerly, adjusting any and all pointers (and > only those) in the Lisp data before the new data is read for the first > time (because what you read might be a pointer, and then it needs to be > adjusted). With fork(), you only have to make the copy when the data is > being written to, by either process. > > (Of course you can just access all memory through some sort of API that > translates addresses for you, but that would effectively mean we'd be > running Emacs on a virtual machine and simulate fork() on it). Could one really avoid global interpreter lock using fork()? It doesn't sound right: even if you get cheap snapshotting using the underlying OS's mechanisms, could we guarantee that the snapshot is "consistent" from the Lisp VM's point of view. Or if Lisp were not in the picture, that the data structures are consistent anyway, unless the second process adheres to the first one's locks anyway. > But, to be perfectly honest, I'm not sure redisplay is slowing me down > the way traditional GC is. IMO redisplay is not the problem most of time indeed. Sometimes it is, but I'm not sure parallelizing the rendering is the best answer in those scenarios either.