# [PATCH] Automatic module globals management - Thread: https://externals.io/message/23988 - Original archive: https://news-web.php.net/php.internals/23988 - Started by Dmitry Stogov on 2006-06-08T12:15:56+00:00 - Messages: 34 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/23988.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #23988 — Dmitry Stogov — 2006-06-08T12:15:56+00:00 URL: https://externals.io/message/23988#23988 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. --- ## #23989 — Steph Fox — 2006-06-08T12:59:41+00:00 URL: https://externals.io/message/23988#23989 · In reply to: #23988 Hey Dmitry, all, Disclaimer: I've had a sneak preview on this one. I really don't like this going into 5_2 branch, and the more I think about it the less sure I am about it going into HEAD either. It would mean renaming all the ctor/dtor functions to the new globals, which is going to take an awful lot of #ifdef'ing in PECL extensions if they're going to retain compatibility across all the current versions of PHP. I've spent some time fiddling with this stuff as a result. In ZTS builds the dtor functions are actually called correctly, at the point when the resource is freed. The original ZTS problem (of how to store the TSRM resource ID in the zend_module_entry struct) is resolvable without going to all those lengths - I have it running locally and can provide a patch when I clean up my source - but would still involve a change to the module API, because that's unavoidable. Just a far less radical change from the perspective of extension authors. In non-ZTS builds the dtor functions are only called from MSHUTDOWN, and that's a separate issue altogether. I've been toying with the idea of storing a pointer to the dtor (where one exists) in a hashtable keyed on module name and calling it from the module destructor. I've got as far as the module destructor recognising when there's a dtor declared in ZEND_INIT_MODULE_GLOBALS, but the next part's kind of eluding me at present. If you're interested I'll pull together what I have so far and send it over to the experts :) The 'down' side is that I don't know how much storing extension dtor info in this way would impact startup speed, and I've no way to check. But then again I don't know how storing it in the module struct would impact startup speed either... - Steph ----- Original Message ----- From: "Dmitry Stogov" To: ; "Ilia Alshanetsky" Cc: "Andi Gutmans" ; "Steph" Sent: Thursday, June 08, 2006 2:15 PM Subject: [PHP-DEV] [PATCH] Automatic module globals management > 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. > > > __________ 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 --- ## #23990 — Sara Golemon — 2006-06-08T15:50:13+00:00 URL: https://externals.io/message/23988#23990 · In reply to: #23988 > 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. > Dmitry- I like the concept especially as it makes this part of the lifecycle-loop consistent with the RINIT/SHUTDOWN MINIT/SHUTDOWN design.... Having said that I like it, here's what I'd change: *) Nomenclature: I'd like to see MGCTOR/MGDTOR (and their proto wrappers) named more consistently with [RM]INIT/SHUTDOWN. e.g. GINIT/GSHUTDOWN or TINIT/TSHUTDOWN *) There are some WS problems in your patch to posix.c > I really don't like this going into 5_2 branch, and > the more I think about it the less sure I am about > it going into HEAD either. It would mean renaming > all the ctor/dtor functions to the new globals, which > is going to take an awful lot of #ifdef'ing in PECL > extensions if they're going to retain compatibility > across all the current versions of PHP. > Steph- I think you're missing the fact that Dmitry's patch only *enables* an extension to register CTOR/DTORs in the module entry struct. Existing modules can continue to use the manual calls in MINIT/MSHUTDOWN without breaking. -Sara --- ## #23991 — Steph Fox — 2006-06-08T16:10:57+00:00 URL: https://externals.io/message/23988#23991 · In reply to: #23990 Hi Sara, > I think you're missing the fact that Dmitry's patch only *enables* an > extension to register CTOR/DTORs in the module entry struct. Existing > modules can continue to use the manual calls in MINIT/MSHUTDOWN without > breaking. Yes, I know. But altered modules won't be able to use older versions of PHP readily, and that's going to be a real problem in PECL - especially if this goes into 5_2 branch. - Steph --- ## #23992 — Sara Golemon — 2006-06-08T16:43:47+00:00 URL: https://externals.io/message/23988#23992 · In reply to: #23991 > Yes, I know. But altered modules won't be able to use older versions of > PHP readily, and that's going to be a real problem in PECL - especially if > this goes into 5_2 branch. > For the modules which are part of the core distribution this is a non-issue as they're branched. For PECL modules this is the same "how old of a PHP version am I (as the package maintainer) willing to support?". That package maintainer can: (A) Not use the new API, (B) Wrap up some #ifdef's, or (C) Use the new API exclusively and eschew pre-5.2. Personally, I'm not going to actually use the GINIT/GSHUTDOWN methods in extensions like runkit (probably ever) as they're enough of a problem maintaining PHP 4.0 compatability as it is. For exts that already require 5.0+, I probably will fold in the use of these after 6.0's release (at which point 5.2 will be established and in {relatively} wide use). Allowing the engine to exprt this functionality doesn't automatically break anything, but when modules *do* switch to the new API, having support for it going back to 5.2 will be *better* than only having the support go back to 6.0. -Sara --- ## #23993 — Steph Fox — 2006-06-08T16:46:11+00:00 URL: https://externals.io/message/23988#23993 · In reply to: #23992 > > […] > For the modules which are part of the core distribution this is a > non-issue as they're branched. For PECL modules this is the same "how old > of a PHP version am I (as the package maintainer) willing to support?". > That package maintainer can: (A) Not use the new API, (B) Wrap up some > #ifdef's, or (C) Use the new API exclusively and eschew pre-5.2. Right, and that's why I think it's problematic to have such a major change in the API, because (A) and (C) are the likeliest outcomes - (B) is virtually unmanageable. Take a look at what it takes for an extension to adapt to this, and then imagine all of it #ifdef'd.... - Steph --- ## #23994 — Stanislav Malyshev — 2006-06-08T16:57:13+00:00 URL: https://externals.io/message/23988#23994 · In reply to: #23988 DS>>The attached patch (for PHP_5_2) implements automatic management of module DS>>globals. DS>>The problem that module globals must be unregistered before extension DS>>unloading, because "globls_dtor" function is unloaded together with DS>>extension and cannot be called. I think the patch itself looks fine, and makes globals management cleaner. However, I'm not sure it would be for 5.2 for reasons cited by Steph - probably not a lot of extension would be reworked specifically for 5.2 (correct me if I'm wrong here) but for 6.0 probably most of them would need some massaging here and there, so putting it in 6.0 is quite OK, but putting it into 5.2 probably would not be used too much outside the engine modules - for which it doesn't matter much since we can fix them with old API as far as I see. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115 --- ## #23995 — Steph Fox — 2006-06-08T17:02:54+00:00 URL: https://externals.io/message/23988#23995 · In reply to: #23994 > DS>>The attached patch (for PHP_5_2) implements automatic management of > module > DS>>globals. > DS>>The problem that module globals must be unregistered before extension > DS>>unloading, because "globls_dtor" function is unloaded together with > DS>>extension and cannot be called. > > I think the patch itself looks fine, and makes globals management cleaner. > However, I'm not sure it would be for 5.2 for reasons cited by Steph - > probably not a lot of extension would be reworked specifically for 5.2 > (correct me if I'm wrong here) but for 6.0 probably most of them would > need some massaging here and there, so putting it in 6.0 is quite OK, but > putting it into 5.2 probably would not be used too much outside the engine > modules - for which it doesn't matter much since we can fix them with old > API as far as I see. We can, but Dmitry broke the old API for win32 with his DL_UNLOAD exposure (which is where this redesign began). So a lot of modules simply won't work there without a little massaging at present - not a huge problem within PHP itself, but a niggling one for anyone with a non-public extension who thought they could just upgrade to PHP 5.1.3 and up. (A _very_ little massaging, but it's still a broken API.) I think we need to fix that API breakage in 5_2 regardless of what happens with this patch... - Steph --- ## #23996 — Sara Golemon — 2006-06-08T17:39:50+00:00 URL: https://externals.io/message/23988#23996 · In reply to: #23993 > > […] > > Right, and that's why I think it's problematic to have such a major change > in the API, because (A) and (C) are the likeliest outcomes - (B) is > virtually unmanageable. Take a look at what it takes for an extension to > adapt to this, and then imagine all of it #ifdef'd.... > The important part of (A) is "not yet" (which I tried to express in my second paragraph). It's the same reason why userspace package maintainers aren't using exceptions and other 5.x specific features en masse *yet*, and why goto won't be used in many scripts when 6.0 is first out -- okay, not the only reason why it won't be used :) As for (C), I can't imagine an extension maintainer going that route unless they have other *more compelling* reasons to give up on pre-5.2 versions. There's just not enough of a win to merit alienating those earlier versions *yet*. Noone's forcing module authors to break compatability with older versions, this is just giving them the choice to do so, and get a cleaner piece of source in the process. It's also making it so that when those extension maintainers do reach that point, they don't have to alienate the (presumably larger) pre-6.0 audience, they only have to do so for the (smaller) pre-5.2 audience. I'm sorry Steph, I know your position, but I just don't understand it. This is a minor gain at no cost. Minor enough that it's not worth it to me to fight with you over it, but no-cost enough to compel me to against my better judgement... :) -Sara --- ## #23997 — Steph Fox — 2006-06-08T17:42:33+00:00 URL: https://externals.io/message/23988#23997 · In reply to: #23996 > I'm sorry Steph, I know your position, but I just don't understand it. > This is a minor gain at no cost. Minor enough that it's not worth it to > me to fight with you over it, but no-cost enough to compel me to against > my better judgement... :) That's because you're missing that this was originally offered as a FIX.... > > -Sara --- ## #23998 — Andi Gutmans — 2006-06-08T18:03:29+00:00 URL: https://externals.io/message/23988#23998 · In reply to: #23988 I read the whole thread. I agree with Sara. While I understand where Steph is coming from, I still think this is a good change. It would allow us to use this method in the current tree right away, and for PECL authors who want to stay compatible with older versions they can use the old & ugly way of doing it until they feel comfortable in changing over. I also second Sara on the naming changes of the macros. They ones suggested by Dmitry didn't appeal to me either :) Andi At 05:15 AM 6/8/2006, 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. --- ## #23999 — Steph Fox — 2006-06-08T18:18:11+00:00 URL: https://externals.io/message/23988#23999 · In reply to: #23998 Andi, hi, >I read the whole thread. > I agree with Sara. While I understand where Steph is coming from, I still > think this is a good change. It would allow us to use this method in the > current tree right away, and for PECL authors who want to stay compatible > with older versions they can use the old & ugly way of doing it until they > feel comfortable in changing over. This redesign was presented as a fix for a win32 module API breakage in PHP 5.1.3 that causes shared modules to crash. Adopting the proposed changes now won't help in any way for existing extensions, since everyone's saying 'oh it'll be nice to use it in the future'. It just means we're stuck with the status quo, and of course the odd confused extension author turning up with a strange shutdown crash under win32 that didn't used to happen in PHP 5.1.2. It'd make more sense to apply the patch partially in 5_2 and change the module API number (to address that issue and give extension authors some hope of understanding what's going on), and apply the whole thing in HEAD and bump the API number again. I really think applying it in 5_2 is going to leave extension writers with a headache. - Steph --- ## #24000 — Rasmus Lerdorf — 2006-06-08T18:24:45+00:00 URL: https://externals.io/message/23988#24000 · In reply to: #23999 Steph Fox wrote: > Andi, hi, > > > > […] > > This redesign was presented as a fix for a win32 module API breakage in > PHP 5.1.3 that causes shared modules to crash. Adopting the proposed > changes now won't help in any way for existing extensions, since > everyone's saying 'oh it'll be nice to use it in the future'. It just > means we're stuck with the status quo, and of course the odd confused > extension author turning up with a strange shutdown crash under win32 > that didn't used to happen in PHP 5.1.2. > > It'd make more sense to apply the patch partially in 5_2 and change the > module API number (to address that issue and give extension authors some > hope of understanding what's going on), and apply the whole thing in > HEAD and bump the API number again. I really think applying it in 5_2 is > going to leave extension writers with a headache. As soon as you change the module api number you have a headache. At Yahoo! we would need to compile some 200 or so custom extensions. If we are forced to do that, a little tweak in the code itself is minor. -Rasmus --- ## #24001 — Andi Gutmans — 2006-06-08T18:27:27+00:00 URL: https://externals.io/message/23988#24001 · In reply to: #23999 It's not going to be a headache because they can still use it the way it should be done today. For the 5.1.x tree you can do the fixes immediately with the way Dmitry has previously proposed.... At 11:18 AM 6/8/2006, Steph Fox wrote: >Andi, hi, > > > > […] > >This redesign was presented as a fix for a win32 module API breakage >in PHP 5.1.3 that causes shared modules to crash. Adopting the >proposed changes now won't help in any way for existing extensions, >since everyone's saying 'oh it'll be nice to use it in the future'. >It just means we're stuck with the status quo, and of course the odd >confused extension author turning up with a strange shutdown crash >under win32 that didn't used to happen in PHP 5.1.2. > >It'd make more sense to apply the patch partially in 5_2 and change >the module API number (to address that issue and give extension >authors some hope of understanding what's going on), and apply the >whole thing in HEAD and bump the API number again. I really think >applying it in 5_2 is going to leave extension writers with a headache. > >- Steph --- ## #24002 — Steph Fox — 2006-06-08T18:29:09+00:00 URL: https://externals.io/message/23988#24002 · In reply to: #24000 Hi Rasmus, > > […] > > As soon as you change the module api number you have a headache. At > Yahoo! we would need to compile some 200 or so custom extensions. If we > are forced to do that, a little tweak in the code itself is minor. We aren't _forced_ to do that, I wrote a small patch over a week ago that fixes it internally and doesn't even touch the module_entry struct. But the more robust way would be to do as Dmitry's suggesting with the ZEND_MG(whatever) part of his patch. People with custom extensions at least are only working with one version of PHP at a time, I'd hope :) > > -Rasmus --- ## #24003 — Steph Fox — 2006-06-08T18:33:04+00:00 URL: https://externals.io/message/23988#24003 · In reply to: #24001 > It's not going to be a headache because they can still use it the way it > should be done today. ... for the last two months or so... that's not a 'should', that's a workaround. > For the 5.1.x tree you can do the fixes immediately with the way Dmitry > has previously proposed.... Huh? Did I miss something? - Steph --- ## #24004 — Pierre — 2006-06-08T18:40:09+00:00 URL: https://externals.io/message/23988#24004 · In reply to: #24002 > People with custom extensions at least are only working with one version of > PHP at a time, I'd hope :) Not really. Especially not when you provide it as a product. --Pierre --- ## #24005 — Andi Gutmans — 2006-06-08T18:40:39+00:00 URL: https://externals.io/message/23988#24005 · In reply to: #24003 At 11:33 AM 6/8/2006, Steph Fox wrote: > > […] > >... for the last two months or so... that's not a 'should', that's >a workaround. > > > […] > >Huh? Did I miss something? I mean the infamous #ifdef in MSHUTDOWN :) Steph, let me think about it more and review your patch again for 5.1. Andi --- ## #24007 — Derick Rethans — 2006-06-08T18:52:56+00:00 URL: https://externals.io/message/23988#24007 · In reply to: #24002 > People with custom extensions at least are only working with one version of > PHP at a time, I'd hope :) Are you kidding? There are people using Xdebug for PHP 4.3.x, 4.4.x, 5.0.x, 5.1.x and 5.2.x... that's already enough headaches to maintain with ifdefs all over the place. regards, Derick --- ## #24011 — Ilia Alshanetsky — 2006-06-08T21:31:39+00:00 URL: https://externals.io/message/23988#24011 · In reply to: #23988 The patch is good, but I think this change maybe a bit too extreme for PHP 5.2 > 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. > Ilia Alshanetsky --- ## #24012 — Pierre — 2006-06-08T21:34:10+00:00 URL: https://externals.io/message/23988#24012 · In reply to: #24011 > The patch is good, but I think this change maybe a bit too extreme > for PHP 5.2 I agree. As far as I remember, we even discussed a similar solution some years ago and decided to delay it until someone comes with a better one, which indeed did not happen ;) I do not see a problem to commit in HEAD and test it, no? We can always add it later to 5.x. If 5.x still exists :-D --Pierre --- ## #24014 — Andi Gutmans — 2006-06-08T23:44:33+00:00 URL: https://externals.io/message/23988#24014 · In reply to: #24011 Why so? It doesn't affect any compatibility. 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 > > > > > > […] > >Ilia Alshanetsky --- ## #24015 — Pierre — 2006-06-09T00:09:04+00:00 URL: https://externals.io/message/23988#24015 · In reply to: #24012 On Thu, 8 Jun 2006 23:34:10 +0200 pierre.php@gmail.com (Pierre) wrote: > > > […] > > I agree. As far as I remember, we even discussed a similar solution > some years ago and decided to delay it until someone comes with a > better one, which indeed did not happen ;) > > I do not see a problem to commit in HEAD and test it, no? We can > always add it later to 5.x. If 5.x still exists :-D I changed my mind, after having read again the patch (and roughly tested), it would be good to have it in 5.2, the early the better :) -- Pierre --- ## #24016 — Steph Fox — 2006-06-09T03:22:45+00:00 URL: https://externals.io/message/23988#24016 · In reply to: #24014 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: > > […] > > -- > > > > > __________ NOD32 1.1380 (20060125) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com --- ## #24017 — Steph Fox — 2006-06-09T03:44:11+00:00 URL: https://externals.io/message/23988#24017 · In reply to: #24016 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" To: "Ilia Alshanetsky" ; "Dmitry Stogov" ; "Andi Gutmans" Cc: Sent: Friday, June 09, 2006 5:22 AM Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management > Andi, > > > […] > > 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 > > > […] > > > __________ 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 --- Next page: https://externals.io/message/23988.md?page=2