From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Thu, 06 Jul 2023 16:17:02 +0000 Message-ID: <87r0plxbep.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35095"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 06 18:17: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 1qHRfm-0008uT-Ra for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jul 2023 18:17:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHRfM-0002Ln-2t; Thu, 06 Jul 2023 12:17:12 -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-0002LM-7Z for emacs-devel@gnu.org; Thu, 06 Jul 2023 12:17:10 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHRfH-0004C8-E1 for emacs-devel@gnu.org; Thu, 06 Jul 2023 12:17:09 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 11DA2240029 for ; Thu, 6 Jul 2023 18:17:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688660225; bh=RtD/i3BXbPRbW0XHXo3+EuIosDFn4r5/IPbWkoFkEhA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=d9+5ix2erwZHJz6azteFsiwZO4bJ2dYGjuDG2HTE0tY016eWgn6wxW/Epe1ylzVGX 32zQb7MNq8YDlc3Lsp/TMYIGfb2FsEl3Z1WvC2qNK3oF1+0qgA6OsNwumVqt2i0nOn zrOBXiL8kNOCZc/p7oJTqnTphw6j6qTOh990LllK+zgomjC1BeaKt3tf7IxeXIwurc yQcBkgS+bseMqOXna1j7GX+iZ5E4gKdYhYRsrW8auzvo2eN0FkB4P9mGxWCud86p4n 98rFfaMOz4bbiNTYgUuc4T/ETOg2NgATk2+JQLmOri9+O0ycmXg62yDwnT+z2fKrYl 9IHDFB1ktdTHA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QxhW443Y9z6txT; Thu, 6 Jul 2023 18:17:04 +0200 (CEST) In-Reply-To: <83sfa1gjns.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:307518 Archived-At: 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? >From my understanding, GC is now called in specific places in subr code. If we consider scenario when multiple Emacs threads are running and one is requesting GC, it should be acceptable to delay that request and wait until all other threads eventually arrive to GC call. Once that is done, GC is safe to run. 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at