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: Sun, 02 Jan 2022 08:54:54 +0200 Message-ID: <83tuemeif5.fsf@gnu.org> References: <878rw1pvcw.fsf@logand.com> <83r19tgqlq.fsf@gnu.org> <87v8z5nmsp.fsf@logand.com> <875yr3krs5.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20059"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudi@constantly.at, emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 02 07:58:00 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 1n3uoa-00054R-3Q for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Jan 2022 07:58:00 +0100 Original-Received: from localhost ([::1]:32998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3uoY-0006AN-So for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Jan 2022 01:57:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3ulc-0004f1-Rq for emacs-devel@gnu.org; Sun, 02 Jan 2022 01:54:56 -0500 Original-Received: from [2001:470:142:3::e] (port=50440 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 1n3ulb-0005IQ-TG; Sun, 02 Jan 2022 01:54:55 -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=riYSJ440PiRTzC6m+Q9OfEWmX3177FkKbgXDVt6SFqg=; b=WvIt05+y76b7 84pjxKkOjnX5N8FnAIVbbb12XMmfR8PEnX+tv7upXtponKNRxJB6su578FihsKjIh4ZO+hBimu1QA 9gsief0Uqc6Vw3HiW7DFA8AhxwzNxKOTSSLSrCRay9k3aEE1hVAjJcHmEHn05jYpSErDPTB5NAMq2 5fuVXISBRS2Eka3HtYz099Tq+y8r7aUuQPnSql/zc6+gX6g28U/gOqqB/pDDhFSvRRpyKMcOYuKS5 4dol615IsJiU1uWoSEaKXq0yc4HXm4keMughQJwm9nilFLBlx0Uua9pdSZVThpLLZ1xNvDHs9RGd+ UVi0RZudYNpNSWjMBOHQBw==; Original-Received: from [87.69.77.57] (port=1796 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 1n3ulZ-0004Uc-1E; Sun, 02 Jan 2022 01:54:56 -0500 In-Reply-To: <875yr3krs5.fsf@logand.com> (message from Tomas Hlavaty on Sat, 01 Jan 2022 23:36:10 +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:283855 Archived-At: > From: Tomas Hlavaty > Date: Sat, 01 Jan 2022 23:36:10 +0100 > > Lets have a look at the function directory-files. It is likely the > worst possible API for accessing filesystem. (Common Lisp has the same > flaw.) It opens a directory, does its work and closes the directory. > Nice, it is done "properly": open, work, close. The problem is, that > the amount of work done inside open/close is not under control of the > programmer and is not bound in space and time. Additionally, the whole > work needs to be done completely, or completely aborted. It means that > unless the amount of work is trivial, the whole thing and all the things > that are built on top of it are useless. That sounds a bit extreme > claim. Lets test it with something real: M-x find-lisp-find-dired > /nix/store [.]service$. While Emacs blocked, no results seen. C-g > after several seconds. That was not very useful. Lets try M-x > find-dired /nix/store -name '*.service'. That works nicely. Why? > Because the directory traversal runs in a second process (the control > loop pushes the results out of the process step by step) and the first > emacs process displays the results step by step as they come (with > directory entry granularity). How could find-lisp-find-dired be fixed? > Could it be fixed while still using directory-files? I do not think so. > I guess it can only be fixed by pushing directory entries out from > another thread (like find-dired does) or using a "stream" of directory > entries pulled on demand. One common paradigm for such use cases is to use a callback: the function that traverses some collection of objects calls that callback for every object it finds. There are usually protocols for the callback to stop the process and prevent the rest of objects from being examined/reported. > But when should close be called, when such stream is lazy? I am > sure a reasonable ad-hoc solution could be implemented. But what if > the directory is traversed recursively? When should each close be > called? A case for another ad-hoc solution? Looks like finalizers > would be great here. We have the unwind-protect machinery in place for that. In fact, if you look at the implementation of directory-files, you will see that it already uses that machinery, and it most probably actually kicked in when you typed C-g above.