Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Internal properties »

Internal properties

php.internals

Andrei Zmievski

22 years ago
Hi, I saw this in zend_opcode.c zend_cleanup_class_data(): /* Note that only run-time accessed data need to be cleaned up, * pre-defined data can not contain objects and thus are not probelmatic */ Which lead me to look into zend_declare_property() and I noticed that you cannot declare properties that are objects/arrays/resources. Is there a good reason for disallowing extension authors to do that? Alternatively, do you suggest using zend_hash_update() on class properties even though I really need this property to be static so its shared by all instances of the class? -Andrei * Unix is user friendly, it is just chooses its users selectively. *

Andi Gutmans

22 years ago
At 11:01 PM 7/21/2004 -0700, Andrei Zmievski wrote:
>Hi, > >I saw this in zend_opcode.c zend_cleanup_class_data(): > > /* Note that only run-time accessed data need to be cleaned up, > * pre-defined data can not contain objects and thus are > not probelmatic */ > >Which lead me to look into zend_declare_property() and I noticed that >you cannot declare properties that are objects/arrays/resources. Is >there a good reason for disallowing extension authors to do that?
The problem is that objects and resources can't really stay alive in between requests because those mechanisms are shutdown at rshutdown. Arrays also can't stay alive because they need to be emalloc()'ed or they won't work with the engine. I think it'd be quite complex to change this behavior and the work around probably needs to be in the extension depending on how bad it is to recreate these or somehow cache them for rinit.
>Alternatively, do you suggest using zend_hash_update() on class >properties even though I really need this property to be static so its >shared by all instances of the class?
If these are per-request statics it can probably be solved. Andi

David Sklar

22 years ago
Marcus and I briefly discussed creating properties that are arrays in this thread: --> http://www.zend.com/lists/php-dev/200405/msg00221.html I posted some code that was working for me, but perhaps it has problems? David Andi Gutmans wrote:

Andrei Zmievski

22 years ago
On Wed, 21 Jul 2004, Andi Gutmans wrote:
> >Alternatively, do you suggest using zend_hash_update() on class > >properties even though I really need this property to be static so its > >shared by all instances of the class? > > If these are per-request statics it can probably be solved.
How could it be solved? - Andrei

Marcus Börger

22 years ago
Hello Andi, Thursday, July 22, 2004, 8:16:10 AM, you wrote:
> At 11:01 PM 7/21/2004 -0700, Andrei Zmievski wrote: >>Hi, >> >>I saw this in zend_opcode.c zend_cleanup_class_data(): >> >> /* Note that only run-time accessed data need to be cleaned up, >> * pre-defined data can not contain objects and thus are >> not probelmatic */ >> >>Which lead me to look into zend_declare_property() and I noticed that >>you cannot declare properties that are objects/arrays/resources. Is >>there a good reason for disallowing extension authors to do that?
> The problem is that objects and resources can't really stay alive in > between requests because those mechanisms are shutdown at rshutdown. Arrays > also can't stay alive because they need to be emalloc()'ed or they won't > work with the engine.
I rememer seeing a patch that gave anything that was allocated (either malloc or emalloc or whatever_alloc) a destructor function pointer alias free. Wouldn't that solve any related problem?
-- Best regards, Marcus mailto:helly@php.net

Andi Gutmans

22 years ago
At 10:45 AM 7/22/2004 -0700, Andrei Zmievski wrote:
>On Wed, 21 Jul 2004, Andi Gutmans wrote: > > >Alternatively, do you suggest using zend_hash_update() on class > > >properties even though I really need this property to be static so its > > >shared by all instances of the class? > > > > If these are per-request statics it can probably be solved. > >How could it be solved?
I assume we could create them on rinit and nuke them at rshutdown. Checking it exactly will take me some time. Andi

Andrei Zmievski

22 years ago
On Thu, 22 Jul 2004, Andi Gutmans wrote:
> I assume we could create them on rinit and nuke them at rshutdown. > Checking it exactly will take me some time.
That's fine. Even supporting only per-request statics would be nice. I assume they would have to be declared via a different API? - Andrei

Andi Gutmans

22 years ago
At 01:42 PM 7/22/2004 -0700, Andrei Zmievski wrote:
>On Thu, 22 Jul 2004, Andi Gutmans wrote: > > I assume we could create them on rinit and nuke them at rshutdown. > > Checking it exactly will take me some time. > >That's fine. Even supporting only per-request statics would be nice. I >assume they would have to be declared via a different API?
Yes, I think so. Hopefully I'll have time to take a look at it tomorrow. If you don't want to wait, go ahead and see if you find anything interesting and mail me. I'm sure we'll find some solution. Andi

Andrei Zmievski

22 years ago
On Thu, 22 Jul 2004, Andi Gutmans wrote:
> Yes, I think so. Hopefully I'll have time to take a look at it tomorrow. > If you don't want to wait, go ahead and see if you find anything > interesting and mail me. I'm sure we'll find some solution.
I can wait. I just want to know whether this is something that we can have in 5.0.x release, because I need it for PHP-GTK 2. - Andrei

Andrei Zmievski

22 years ago
On Thu, 22 Jul 2004, Andi Gutmans wrote:
> Yes, I think so. Hopefully I'll have time to take a look at it tomorrow. > If you don't want to wait, go ahead and see if you find anything > interesting and mail me. I'm sure we'll find some solution.
It would be also good to think about doing same for constants. That is, allowing objects/arrays/resources as non-persistent constants that will be cleaned up at the end of the request. -Andrei Documentation is worth it just to be able to answer all your mail with 'RTFM'. -- Alan Cox

Andi Gutmans

22 years ago
Don't quite understand what you're suggesting.. Sorry. Can you please explain it again? At 08:44 PM 7/22/2004 +0200, Marcus Boerger wrote:

Marcus Börger

22 years ago
Hello Andi, i remember something where each zval had pointer to a free function to free it's memory. regards marcus Thursday, July 22, 2004, 9:00:27 PM, you wrote:
> Don't quite understand what you're suggesting.. Sorry. Can you please > explain it again?
> At 08:44 PM 7/22/2004 +0200, Marcus Boerger wrote: >>Hello Andi, >> >>Thursday, July 22, 2004, 8:16:10 AM, you wrote: >> >> > At 11:01 PM 7/21/2004 -0700, Andrei Zmievski wrote: >> >>Hi, >> >> >> >>I saw this in zend_opcode.c zend_cleanup_class_data(): >> >> >> >> /* Note that only run-time accessed data need to be cleaned up, >> >> * pre-defined data can not contain objects and thus are >> >> not probelmatic */ >> >> >> >>Which lead me to look into zend_declare_property() and I noticed that >> >>you cannot declare properties that are objects/arrays/resources. Is >> >>there a good reason for disallowing extension authors to do that? >> >> > The problem is that objects and resources can't really stay alive in >> > between requests because those mechanisms are shutdown at rshutdown. Arrays >> > also can't stay alive because they need to be emalloc()'ed or they won't >> > work with the engine. >> >>I rememer seeing a patch that gave anything that was allocated (either >>malloc or emalloc or whatever_alloc) a destructor function pointer alias >>free. Wouldn't that solve any related problem? >> >>-- >>Best regards, >> Marcus mailto:helly@php.net
-- Best regards, Marcus mailto:helly@php.net

Andi Gutmans

22 years ago
Yeah but besides hurting performance that would waste an additional pointer of storage for each memory block. Not something I'd like to do. Andi At 12:05 AM 7/23/2004 +0200, Marcus Boerger wrote:

Marcus Börger

22 years ago
Hello Andi, Friday, July 23, 2004, 1:26:40 AM, you wrote:
> Yeah but besides hurting performance that would waste an additional pointer > of storage for each memory block. Not something I'd like to do.
Yep, that's the bad point of it: additional 4 bytes for every zval (on 32 bit machines). marcus