Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24087 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11310 invoked by uid 1010); 11 Jun 2006 07:52:12 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 11295 invoked from network); 11 Jun 2006 07:52:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jun 2006 07:52:12 -0000 X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:30856] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id E0/3C-30619-AABCB844 for ; Sun, 11 Jun 2006 03:52:11 -0400 Received: (qmail 31991 invoked from network); 11 Jun 2006 07:51:38 -0000 Received: from shire.zend.office (10.1.2.160) by internal.zend.office with SMTP; 11 Jun 2006 07:51:38 -0000 Date: Sun, 11 Jun 2006 10:51:37 +0300 (IDT) X-X-Sender: frodo@shire.zend.office To: Steph Fox cc: internals@lists.php.net In-Reply-To: <178401c68bf7$0818bde0$6602a8c0@foxbox> Message-ID: References: <000001c68af5$50876930$6e02a8c0@thinkpad><7B45819D-6E8D-4B9B-A02B-BC00BE6B1930@prohost.org> <7.0.1.0.2.20060608164415.06b4ae50@zend.com> <133f01c68b73$fb1a1bd0$6602a8c0@foxbox> <145901c68bad$cdd4b470$6602a8c0@foxbox> <165e01c68be9$afb4cb60$6602a8c0@foxbox> <178401c68bf7$0818bde0$6602a8c0@foxbox> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management From: stas@zend.com (Stanislav Malyshev) SF>>Erm, Stas, it's not because it's impossible - it's because that SF>>module_shutdown_func happens to be the module's MSHUTDOWN. The contents of SF>>MSHUTDOWN generally look something like: SF>> SF>>#ifdef ZTS SF>>ts_free_id(pcre_globals_id); SF>>#else SF>>php_pcre_shutdown_globals(&pcre_globals TSRMLS_CC); SF>>#endif SF>> SF>>UNREGISTER_INI_ENTRIES(); SF>> SF>>return SUCCESS; That's quite an assumption. What if it looks like: if(MODULE_G(flag)) { do_complicated_shutdown(MODULE_G(data)); } before your code, and you have already freed the MODULE_G's id? SF>>I'm not changing a darn thing in the order of the calls there, and that's SF>>*exactly* why I don't get your point. You are changing the order of ts_free_id's however - once you assumption of "one alloc exactly per module" is wrong, you can have free_id before dtor is called. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115