Re: using finalizers

[Eli Zaretskii <eliz@gnu.org>]

> From: Tomas Hlavaty <tom@logand.com>
> 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.