y Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>; "'Stanislav Malyshev'"
<[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, June 13, 2006 3:22 PM
Subject: RE: [PHP-DEV] Re: [PATCH] Automatic module globals management
> Step
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 13, 2006 6:24 PM
> To: Dmitry Stogov; 'Stanislav Malyshev'
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
>
sage -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>; "'Stanislav Malyshev'" <[EMAIL
PROTECTED]>
Cc:
Sent: Tuesday, June 13, 2006 3:22 PM
Subject: RE: [PHP-DEV] Re: [PATCH] Automatic modul
itry.
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 11, 2006 12:49 PM
> To: Stanislav Malyshev
> Cc: Dmitry Stogov; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
>
>
> Hi
Hi Stas
SF>>resource id, and it would need to be a ZTS build. Whatever way you
look at
SF>>it, that's a screwed up configuration.
So we would blame the user for our broken code. Do you think it's a good
idea.
No I don't, so I wrote something completely different. Is the attached a
better s
SF>>You'd need to be _dynamically_ loading somewhere over 24 modules for that to
SF>>happen, and this is me testing with a --disable-all build. Normally it'd be
So what? What is so special in number 24 that it can never happen? 640K of
memory is enough for everybody, right? That's exactly what I
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
SF>>How is it going to be dependent in any way on a module that was loaded
SF>>after it was?!
As far as understand the code, table_size - zend_dl_module_count() formula
starts with last allocated ID and deallocates one ID per module unloaded,
starting from the latest loaded module. However, if th
SF>>Because we need to work through one resource at a time from the top,
SF>>and because dl'd modules are the last things with a resource id to be
SF>>loaded, because they have to be.
As you see belowe, this is not correct.
SF>>You got me there. OK, I didn't know that happens until just now. The
SF>>How is it going to be dependent in any way on a module that was loaded
SF>>after it was?!
As far as understand the code, table_size - zend_dl_module_count() formula
starts with last allocated ID and deallocates one ID per module unloaded,
starting from the latest loaded module. However, if
SF>>Because we need to work through one resource at a time from the top,
SF>>and because dl'd modules are the last things with a resource id to be
SF>>loaded, because they have to be.
As you see belowe, this is not correct.
SF>>You got me there. OK, I didn't know that happens until just now. Th
My comments went something along the lines of 'well if it's going in can we
please apply a fix for the problem this was supposed to fix in the first
place, because it isn't an answer to that problem'. I'd still personally
rather it didn't, but I'm happy so long as we get an actual fix in there
SF>>crash might well appear random.) The best way to deal with an
extension
SF>>declaring more than one thread resource would be to build it as
static. But
That's a good advice but not practical at all. :) Static extensions can
not be distributed as a product or a package, for example.
And as
SF>>The number of the final TSRM resource id that was loaded will be the
SF>>size of the table they're stored in, plus one (to keep life simple).
SF>>So we pick up that figure and call it 'table_size'. Then we subtract
SF>>the number of modules registered in the dl_module_count.
I'm not sure wh
You're right, Steph's comments threw me off a bit there, but after
reconsidering the patch in detail I think it should be fine for 5.2,
so go ahead and commit it.
On 8-Jun-06, at 7:44 PM, Andi Gutmans wrote:
Why so? It doesn't affect any compatibility.
At 02:31 PM 6/8/2006, Ilia Alshanets
SF>>crash might well appear random.) The best way to deal with an extension
SF>>declaring more than one thread resource would be to build it as static. But
That's a good advice but not practical at all. :) Static extensions can
not be distributed as a product or a package, for example.
SF>>being
SF>>The number of the final TSRM resource id that was loaded will be the
SF>>size of the table they're stored in, plus one (to keep life simple).
SF>>So we pick up that figure and call it 'table_size'. Then we subtract
SF>>the number of modules registered in the dl_module_count.
I'm not sure wh
-related.
Thanks. Dmitry.
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 2:17 PM
To: Dmitry Stogov; 'Stanislav Malyshev'
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
What's
9, 2006 2:17 PM
> To: Dmitry Stogov; 'Stanislav Malyshev'
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
>
>
> What's 'magic' about going 1, 2, 3, 4?
>
> - Original Message -
>
Friday, June 09, 2006 11:42 AM
Subject: RE: [PHP-DEV] Re: [PATCH] Automatic module globals management
I also think that Steph's patch is to magic. :)
Dmitry.
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 12:28 PM
To: Steph Fox
Hi Stas,
SF>>Attached are patches for fixing the win32/ZTS thing only when needed -
SF>>this will _only_ work if you apply Dmitry's patch to 5_2 as well. The
SF>>idea being that this way everybody's covered.
I'm not sure I understand what this line does:
ts_free_id(table_size - zend_dl_module_c
I also think that Steph's patch is to magic. :)
Dmitry.
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 09, 2006 12:28 PM
> To: Steph Fox
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PATCH] A
SF>>Attached are patches for fixing the win32/ZTS thing only when needed -
SF>>this will _only_ work if you apply Dmitry's patch to 5_2 as well. The
SF>>idea being that this way everybody's covered.
I'm not sure I understand what this line does:
ts_free_id(table_size - zend_dl_module_count());
On Fri, 9 Jun 2006, Dmitry Stogov wrote:
> I will rework patch with new names (GINIT/GSHUTDOWN as Sara suggested) and
> commit it into HEAD today or at Thursday.
> According to PHP_5_2 we probably will need voting.
I'm -1 on integrating it into 5.2 then.
regards,
Derick
--
Derick Rethans
http:/
al Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>; "'Ilia Alshanetsky'" <[EMAIL PROTECTED]>;
"'Andi Gutmans'" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, June 09, 20
HEAD? I'm hoping it'll
separate the issues of API redesign vs bugfix...
- Steph
- Original Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>; "'Ilia Alshanetsky'" <[EMAIL P
2006 4:09 AM
> To: internals@lists.php.net; Pierre
> Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
>
>
> On Thu, 8 Jun 2006 23:34:10 +0200
> [EMAIL PROTECTED] (Pierre) wrote:
>
> > On 6/8/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
odule globals, and never call them
directly.
Thanks. Dmitry.
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 09, 2006 7:23 AM
> To: Ilia Alshanetsky; Dmitry Stogov; Andi Gutmans
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV
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 a
On Thu, 8 Jun 2006 23:34:10 +0200
[EMAIL PROTECTED] (Pierre) wrote:
> On 6/8/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> > 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
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
On 8-Jun-06, at 8:15 AM, Dmitry Stogov wrote:
Hi,
The attached patch (for PHP_5_2) implements automatic management of
mod
On 6/8/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
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 di
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
unloa
On Thu, 8 Jun 2006, Steph Fox wrote:
> 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
At 11:33 AM 6/8/2006, Steph Fox wrote:
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
On 6/8/06, Steph Fox <[EMAIL PROTECTED]> wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
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 mi
Hi Rasmus,
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
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,
I read the whole thread.
I agree with Sara. Whi
Steph Fox wrote:
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 version
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
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
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 origina
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, o
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
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
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
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
48 matches
Mail list logo
