From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: using finalizers Date: Fri, 31 Dec 2021 10:31:02 +0100 Message-ID: <87v8z5nmsp.fsf@logand.com> References: <878rw1pvcw.fsf@logand.com> <83r19tgqlq.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="11507"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , LdBeth Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 31 10:32:46 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 1n3EHG-0002pa-0U for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Dec 2021 10:32:46 +0100 Original-Received: from localhost ([::1]:48406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3EHE-0001TP-Dn for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Dec 2021 04:32:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39102) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3EFh-0000PV-6x for emacs-devel@gnu.org; Fri, 31 Dec 2021 04:31:09 -0500 Original-Received: from logand.com ([37.48.87.44]:60992) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3EFe-00084i-LK; Fri, 31 Dec 2021 04:31:08 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 0176A19EC86; Fri, 31 Dec 2021 10:31:03 +0100 (CET) X-Mailer: emacs 27.2 (via feedmail 11-beta-1 I) In-Reply-To: <83r19tgqlq.fsf@gnu.org> Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: 0 X-Spam_score: -0.0 X-Spam_bar: / X-Spam_report: (-0.0 / 5.0 requ) SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable 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" Xref: news.gmane.io gmane.emacs.devel:283725 Archived-At: 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? I can see these cases where garbage collection might not do its job: 1. imprecise gc 2. program exit or abort 3. a leak to be fixed What do you have in mind, that could hold extra unexpected references and not be a leak? Does it mean that for example thunk-delay leaks even though it releases the reference to the body thunk? Does it mean that setting reference to nil in order to dispose an object (as in my original example) is futile? > 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". In the case of imprecise gc "hopefully eventually as needed".