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: Thu, 06 Jul 2023 21:19:13 +0300 Message-ID: <83ilawhpi6.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87pm57pns8.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19681"; 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 Thu Jul 06 20:20:39 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 1qHTap-0004tf-4o for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jul 2023 20:20:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHTZh-0003iH-Fz; Thu, 06 Jul 2023 14:19:29 -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 1qHTZY-0003hN-At for emacs-devel@gnu.org; Thu, 06 Jul 2023 14:19:21 -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 1qHTZY-0002lb-2G; Thu, 06 Jul 2023 14:19:20 -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=64iKQr+XT8dRiYerTsTZxJbtSKmRo4cNuFA24wb8lyA=; b=pdsPcAUaRMcP QLLtvOEo9thfakNAfeJQXVWWWgIOj2p2tK+TitjdsdTbL2VIawB9HTUsDEs2x3nk5akgxOjvClwmp ev2HzKgGE36ZlubNazgaV31ueh4QUQ5n5HViKOIFB3nVAGoZChfOtMerN5Nc4DqWGoLn8Don/JfOy cG0zWV5c3Vnhl+mEgpNEX7YPYhwqiX6EEj9y8mJykSlliPdFEke6pkyJ2zhKjvzBtnT89ZWf0ym0i 0snseKhLJYc9ug9EePc3t4v1WWuzZ9oS7DrsPq+v3nJzQRTBipt7AdwNL28r+vE2Yhp4qjvuPqkvj gQTp+7ixG2uxdVZ9Vl/e3Q==; 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 1qHTZR-0007l4-N1; Thu, 06 Jul 2023 14:19:19 -0400 In-Reply-To: <87r0plxbep.fsf@localhost> (message from Ihor Radchenko on Thu, 06 Jul 2023 16:17:02 +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:307528 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Thu, 06 Jul 2023 16:17:02 +0000 > > Eli Zaretskii writes: > > >> This does not change my understanding. > >> Locking should prevent manipulations with object data over the time span > >> the code expects the object to be unchanged. > > > > That could defeat GC, should Emacs decide to run it while the lock is > > in place. > > May you elaborate? GC doesn't only free memory used by dead objects. It also performs bookkeeping on live objects: compacts data of strings, relocates text of buffers, compacts the gap in buffers where it became too large, etc. This bookkeeping is more important when Emacs is short on memory: in those cases these bookkeeping tasks might mean the difference between being able to keep the session healthy enough to allow the user to shut down in an orderly fashion. Locking objects means these bookkeeping tasks will be disabled. That could adversely affect the available memory and the memory footprint in general. > Of course, GC calls must not be done while Object lock is in place. But > that's not too different from the existing requirement for GC calls - > they are not sprinkled in arbitrary places. Currently, once GC starts it is free to do all of its parts. If locking prevents GC altogether, your proposal is even worse than I feared. Especially since as long as some thread runs, some objects will be locked, and GC will not be able to run at all.