[PATCH] Keeping module dtors kosher for PHP 5* [WAS: [PATCH] Automatic module globals management]

From: Date: Fri, 09 Jun 2006 03:44:11 +0000
Subject: [PATCH] Keeping module dtors kosher for PHP 5* [WAS: [PATCH] Automatic module globals management]
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-24017@lists.php.net to get a copy of this message
I've done it again - this was an invisible patch :) OK, relabelling the email. Nothing new to see here, move along... ----- Original Message ----- From: "Steph Fox" <steph@zend.com> To: "Ilia Alshanetsky" <ilia@prohost.org>; "Dmitry Stogov" <dmitry@zend.com>; "Andi Gutmans" <andi@zend.com> Cc: <internals@lists.php.net> Sent: Friday, June 09, 2006 5:22 AM Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
Andi,
Why so? It doesn't affect any compatibility.
Yes it does, and more particularly it prevents any fix for the win32/ZTS issue until people upgrade to the new module API. If everyone has to add an extra #ifdef into MSHUTDOWN to get around the new situation, but then has to take it away again 2 versions later... bleh... it's all wrong :) Sara said earlier on IRC that it would be good to make the win32/ZTS thing a separate issue. I think so too. Attached are patches for fixing the win32/ZTS thing only when needed - this will _only_ work if you apply Dmitry's patch to 5_2 as well. The idea being that this way everybody's covered. It's similar for 5_1, except that it doesn't need the check for Dmitry's changes. I don't think we'll need my input for HEAD. As someone said earlier, people will make changes for PHP 6.0 that they might not be ready or willing to make for PHP 5.*. A good suggestion Sara came out with for PECL (this was also on IRC) was to have some version check and offer up different #ext.c files accordingly. At present we don't have that option, but we will if the module API number is bumped following Dmitry's changes. I still don't like it - but I'm quite good at smelling the way the goldfish are swimming :-\ - Steph
At 02:31 PM 6/8/2006, Ilia Alshanetsky wrote:
The patch is good, but I think this change maybe a bit too extreme for PHP 5.2 On 8-Jun-06, at 8:15 AM, Dmitry Stogov wrote:
Hi, The attached patch (for PHP_5_2) implements automatic management of module globals. The problem that module globals must be unregistered before extension unloading, because "globls_dtor" function is unloaded together with extension and cannot be called. To solve this problem extension writers now use the following pattern: PHP_MSHUTDOWN_FUNCTION(mod_name) { -#ifdef ZTS
-       ts_free_id(mod_name_globals_id);
-#else
-       mod_name_globals_dtor(&mod_name_globals TSRMLS_CC);
-#endif With my patch, extension writers should just extend module descriptor with globals descriptor and ctor/dtor callbacks.
        PHP_RSHUTDOWN(mod_name),
        PHP_MINFO(mod_name),
        NO_VERSION_YET,
-       STANDARD_MODULE_PROPERTIES
+       NULL,
+       ZEND_MG(mod_name),
+       ZEND_MGCTOR(mod_name),
+       ZEND_MGCTOR(mod_name),
+       STANDARD_MODULE_PROPERTIES_EX2
}; Old extensions are source compatible and may work without modification. The patch modifies only several extensions, but will modify others too. I like commit the patch into HEAD and PHP_5_2. Any objections, additional ideas? Thanks. Dmitry. <zts_globals-2.diff.txt>
Ilia Alshanetsky
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php __________ NOD32 1.1380 (20060125) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com
__________ NOD32 1.1380 (20060125) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com
--------------------------------------------------------------------------------
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php __________ NOD32 1.1380 (20060125) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com


« previous php.internals (#24017) next »