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: Sat, 01 Jan 2022 18:58:01 +0100 Message-ID: <87ee5rl4nq.fsf@logand.com> References: <878rw1pvcw.fsf@logand.com> <83r19tgqlq.fsf@gnu.org> <87v8z5nmsp.fsf@logand.com> <83ilv5gdsk.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="11239"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 01 18:59:10 2022 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 1n3ier-0002lw-Tb for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Jan 2022 18:59:09 +0100 Original-Received: from localhost ([::1]:53008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3ieq-0000RN-Uy for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Jan 2022 12:59:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46868) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3idr-0007hn-59 for emacs-devel@gnu.org; Sat, 01 Jan 2022 12:58:07 -0500 Original-Received: from logand.com ([37.48.87.44]:55112) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3idp-0002AG-Fb; Sat, 01 Jan 2022 12:58:06 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 5E76019EC87; Sat, 1 Jan 2022 18:58:03 +0100 (CET) X-Mailer: emacs 27.2 (via feedmail 11-beta-1 I) In-Reply-To: <83ilv5gdsk.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:283807 Archived-At: On Fri 31 Dec 2021 at 14:27, Eli Zaretskii wrote: > 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. No, that's not what I expect. I even said that. What I meant is that I did not expect some other code not under my control to keep references to the object forever preventing gc to run the finalizer eventually, which is how I understood your reply. I know at least one Lisp which does keeps extra unexpected references to particular kind of objects preventing finalizers to run, so that kind of behaviour would not be unheard of, but I see it as a bug and hope that Emacs does not have that issue. On another note, I see that finalizers are rarely used and tested: ./test/src/alloc-tests.el33: (should (equal (type-of (make-finalizer nil)) 'finalizer))) ./lisp/emacs-lisp/generator.el642: (make-finalizer For example the cps-generate-evaluator function has 70 lines and it is not obvious to me, that the use of finalizer is not buggy. Do you have an advice, how are programmers supposed to test finalizers? My original issue did not run the finalizer because of a bug in my use of letrec. Unless there is a good way to actually trigger the finalizer, there is no good way to test such code paths. Or shall the programmers just hope for the best?