Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125710
Precedence: bulk
MIME-Version: 1.0
References: <e58b4566-25a7-4a33-8550-8dcb6052b784@jnvsor.net>
 <0a45288d-8ae1-4b1c-8836-6bdd1cf34eb2@gmx.de> <faadf801-1b56-41ee-94ee-377d79034bd1@jnvsor.net>
 <c3c32682-22ec-498c-a76d-83358208322f@gmx.de>
In-Reply-To: <c3c32682-22ec-498c-a76d-83358208322f@gmx.de>
Date: Tue, 1 Oct 2024 14:12:14 +0200
Message-ID: <CAP1Jc13nFZWyxtgMDW8tEUtXmsTcPyR_V9VUGUg56dK=uEwAug@mail.gmail.com>
Subject: Re: [PHP-DEV] Protected destructors
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Jonathan Vollebregt <jnv@jnvsor.net>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Christoph,

On Sat, Sep 28, 2024 at 4:47=E2=80=AFPM Christoph M. Becker <cmbecker69@gmx=
.de> wrote:
> > Besides closing resources and killing processes I've seen them store
> > data to disk for caching, remove temp files, call callbacks/dispatch
> > events, change state on other objects, dump stored errors to error_log
> > in a loop in an error handler...
>
> Okay.  My point is that you cannot know (unless there are no circular
> dependencies) *when* a destructor is called by the engine; it may be
> called during some GC run, or during the request shutdown sequence.  As
> it's now, that happens pretty early during shutdown, but that *might*
> change when stream resources are converted to objects.  So you cannot be
> absolutely sure that everything works as expected in destructors.  This
> is a general issue for garbage collected languages; some of these have
> no destructors at all, for such reasons.

I agree. To expand on this, I think that the use of destructors should
be discouraged for many reasons:

 1. Objects with destructors slow down garbage collection due to
potential resurrections. It's not possible to detect resurrections, so
in the presence of destructors the GC has to forget most of its state,
run destructors, and restart.
 2. They may be called in undefined order during GC and shutdown,
including after their dependencies have already been destroyed
 3. They may cause concurrency issues (even in non-concurrent
programs) because they can be called at any time by the GC
 4. They give a false sense of security as destructors will not be
called in case of fatal errors or crashes
 5. Using them to manage non-memory resources (such as file
descriptors, temp files, ...) is not a good idea because the GC is
only triggered by memory metrics. The process may run out of file
descriptors before it triggers a garbage collection, for example.

Part of these problems would be solved by disabling the GC, but
ensuring that large code bases are free of cycles is not an easy task.

Java has deprecated destructors (finalizers) [2] and recommends using
Cleaners [1] instead. Cleaners would resolve the 1st issue, and
partially the 2nd one (for GC, not shutdown), but I'm not entirely
sure they are transposable. Ruby's ObjectSpace.define_finalizer is
similar to Cleaners, AFAIK, in that the finalizer must not reference
the object.

Some use-cases of destructors could be replaced with patterns like
Python's with() [3], Java's try-with [4], or Go's defer [5].

[1] https://docs.oracle.com/javase/9/docs/api/java/lang/ref/Cleaner.html
[2] https://docs.oracle.com/javase/9/docs/api/java/lang/Object.html#finaliz=
e--
[3] https://docs.python.org/3/reference/compound_stmts.html#with
[4] https://docs.oracle.com/javase/8/docs/technotes/guides/language/try-wit=
h-resources.html
[5] https://go.dev/doc/effective_go#defer

Best Regards,
Arnaud