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: using finalizers Date: Fri, 31 Dec 2021 14:27:23 +0200 Message-ID: <83ilv5gdsk.fsf@gnu.org> References: <878rw1pvcw.fsf@logand.com> <83r19tgqlq.fsf@gnu.org> <87v8z5nmsp.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25647"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 31 13:28:38 2021 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 1n3H1R-0006WR-G9 for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Dec 2021 13:28:37 +0100 Original-Received: from localhost ([::1]:59774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3H1Q-0005n6-CS for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Dec 2021 07:28:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3H0C-00050C-2o for emacs-devel@gnu.org; Fri, 31 Dec 2021 07:27:20 -0500 Original-Received: from [2001:470:142:3::e] (port=37046 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3H0B-00066V-Au; Fri, 31 Dec 2021 07:27:19 -0500 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=VIPyPpjvHyuSDrsH4KH6jQGPTka1Wg+79H/TVfOzy14=; b=Zj0a6r3fr4Bo yZv7VBCuiOiBBri6yXrmNHErQb74pJHvVtNR63Q7ZDkn4h8wFixmshvYWU225ZxW0rOTkl+8SUxRE w9WeT9lNcCmwf/ZTSLjfe/X687GFaM9t3leDxM4NY2hyOrXHCBNCUe4ar8ellKESfItbYrfE9eMgA t5MmF8XRXatSjkcgAm/MZbTapVzpeo9uDxZaH74zDNxaAfjMRokw/hTatQPiN1+4azpUaUaguo4Kw fWTPZ0lN/4l2lEoM1O3K2hdVOYVx6ztIC1naoxu0gMzjnYpNoEOmqJbgNR+wmKs3tw034WgHE/SxQ RtEWONSL+otOMZxbLm1cTA==; Original-Received: from [87.69.77.57] (port=3341 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 1n3H09-0001xG-EI; Fri, 31 Dec 2021 07:27:19 -0500 In-Reply-To: <87v8z5nmsp.fsf@logand.com> (message from Tomas Hlavaty on Fri, 31 Dec 2021 10:31:02 +0100) 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" Xref: news.gmane.io gmane.emacs.devel:283736 Archived-At: > From: Tomas Hlavaty > Cc: emacs-devel@gnu.org > Date: Fri, 31 Dec 2021 10:31:02 +0100 > > On Fri 31 Dec 2021 at 09:50, Eli Zaretskii wrote: > > I think that the assumption that a call to garbage-collect will > > necessarily call the finalizer is also problematic: there's usually no > > simple way to make sure there are no references left to the object, > > This breaks my expectations. Could you explain that more? The main aspect to have in mind is that your Lisp code has no direct control on when a given Lisp object is no longer referenced by any other live object. And even if you take care to do that on the Lisp level (something that is notoriously hard, if possible), GC also scans the C stack for anything that looks like a reference to a Lisp object, and marks any such objects as not (yet) collectible. And your Lisp program has no control on what's on the C stack. > Does it mean that for example thunk-delay leaks even though it releases > the reference to the body thunk? If GC doesn't collect an object right away, it doesn't yet mean we have a leak. As long as the object is collected "eventually", we are fine. > Does it mean that setting reference to nil in order to dispose an object > (as in my original example) is futile? It doesn't necessarily guarantee GC will collect the object, yes. > > and GC could have its own ideas when to actually garbage-collect an > > object. > > I don't think timing is an issue. I think the expectation from gc is > that it collects the object "eventually as needed". That does happen, but you seem to expect more: you expect that the object is collected as soon as you do something in Lisp to break the binding between the object and the variable that was bound to it.