Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125701
Message-ID: <c3c32682-22ec-498c-a76d-83358208322f@gmx.de>
Date: Sat, 28 Sep 2024 16:46:36 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Protected destructors
Content-Language: de-DE
To: Jonathan Vollebregt <jnv@jnvsor.net>, internals@lists.php.net
References: <e58b4566-25a7-4a33-8550-8dcb6052b784@jnvsor.net>
 <0a45288d-8ae1-4b1c-8836-6bdd1cf34eb2@gmx.de>
 <faadf801-1b56-41ee-94ee-377d79034bd1@jnvsor.net>
In-Reply-To: <faadf801-1b56-41ee-94ee-377d79034bd1@jnvsor.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:JbZt5Y1AhG4=;3HFo4Xyzp+7eBM1hq+LxN+/35vM
 3dz+9fsYPyWse0aFtiFNMfYHoogpo+wy6YjqzkdZtn572nRYQnc8YskPBHknlqyWV1yepkdVp
 8DN/IQukMR08DY7mriDUCINeQxn1+sPQMGiqxdLmp1OoSIyJ7AfWTRQ/gwRanU9XivAIm8gXD
 CaF5I2fR4thulbHoDH8ty9vkolkW1e3Am+eYTYFvQtjlPnK9rFjiE2RxCTGgyZXwtIgcAe/yY
 zk3K+DJV11gRWjKeYqxQ1UBBi03nWs6TrzZQ0LQTWnZAwfafpkF21rsTEM/eoGtjcntm5by+C
 v5sX58QXRy4pXeyRDPRm2uYNFGbgKqOTtvs+RWTfpA75NEheiyl8bZqCDqbKqvWrsOdWXPwnp
 rGQ4vwiufyaYaZJT9aB98/HAM2iHz2blk5131J94XHAgHZZLUSkLPqwxKD2g9IPBVDTJyTdd3
 3WAXePOiJJ0uN/etdET7zDZ9qLm+qyDh8YQVKUWCkFs6tlSFPIkkho8pdBRDR700KwYiqoWbW
 s+9ws1twKkAKqKG0HjAQTIfKVBF/Te14bknjXrIYXTtO6JYkXNnDmZqBlDOjhn61hMh2OAuJY
 KWBO5s06YA9UeSUe1wgq/F52TSuBF/eHlkK5pCkXyiN0DvedAtEVNH0/tP78vu7LBT3KpZmnC
 2xDiCB0XlFc/rZSPOQoLA0x1OU6G4h8FPfYuygqLTq+CoCQn5+wGVgBTQwE+yL2EPynjUK+Un
 rv0Kc9ednpn0Y/ECoiL+j8rV9SVf4uospEl3f3CKbVzqA0TQ9VXnTjndKC4XuJY1lcukqk3Dp
 qfu0xhirmW74jFZWBjc4gwBw==
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 28.09.2024 at 16:21, Jonathan Vollebregt wrote:

>> Hmm, I wonder about the use-cases of userland destructors.=C2=A0 It see=
ms to
>> me they are mostly useful for sanity checks, and maybe to close
>> resources.=C2=A0 Are there others?
>>
>> If not, I wouldn't worry much about the visibility of destructors,
>> because resources are scheduled for replacement anyway.
>
> 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.

> It looks like there's quite a lot of use-cases for them (Which can go
> wrong if called twice) that don't necessarily require resources to be
> involved

Like I said, I wouldn't be particularly worried about clients calling a
destructor manually (that's a bit different for the engine, since
segfaultish conditions should be avoided).

But I don't have a strong opinion about the visibility of destructors
anyway.  I'm fine with allowing protected constructors.

Christoph