Registering constants to internal classes (ZE2)

php.internals

Moriyoshi Koizumi

23 years ago
Hi, Perhaps I'm missing something, but I noticed the current ZE2 implementation doesn't seem to correctly handle constants registered to internal classes. I tracked down the cause of this problem, and finally figured out that those constants are destroyed by the ordinary zval_ptr_dtor_wrapper() at the destruction of the constant hash after the deactivation of the memory manager. Then I'm putting forward the following ideas to avoid this. 1. Unify the calls of pefree() / efree() by a function pointer followed by the actual memory block which directs to the actual free() implementation the memory block should be freed by. Here's the example stuff I'm referring to: typedef struct _memblk_t { void (*free_fn)(void *ptr); byte blk[]; } memblk_t; void efree_impl(void *ptr) { ... } void pefree_impl(void *ptr) { free(ptr); } void *pemalloc_impl(size_t sz) { return malloc(sz); } void *pemalloc(size_t sz, int persistent) { void *ptr; if (persistent) { ptr = emalloc_impl(sz + sizeof(memblk_t)); ptr->free_fn = efree_impl; } else { ptr = pemalloc_impl(sz + sizeof(memblk_t)); ptr->free_fn = pefree_impl; } return (void *)ptr->blk; } void efree(void *ptr) { memblk_t *actual_head; actual_head = (memblk_t *)((byte *)ptr - &((memblk_t *)0)->blk); actual_head->free_fn((void *)actual_head); } 2. Add some new constructors / destructors dedicated to the persistent zvals, like ALLOC_INIT_PERSISTENT_ZVAL(), persistent_zval_dtor(), or persistent_zval_ptr_dtor(). I don't like this idea though. Any opinions? Moriyoshi

(Marcus Börger)

23 years ago
Hello Moriyoshi, to me that sounds good. Tuesday, July 1, 2003, 7:33:08 PM, you wrote: MK> Hi, MK> Perhaps I'm missing something, but I noticed the current ZE2 MK> implementation doesn't seem to correctly handle constants registered to MK> internal classes. I tracked down the cause of this problem, and finally MK> figured out that those constants are destroyed by the ordinary MK> zval_ptr_dtor_wrapper() at the destruction of the constant hash after the MK> deactivation of the memory manager. Then I'm putting forward the following MK> ideas to avoid this. MK> 1. Unify the calls of pefree() / efree() by a function pointer followed by MK> the actual memory block which directs to the actual free() implementation MK> the memory block should be freed by. Here's the example stuff I'm MK> referring to: MK> typedef struct _memblk_t { MK> void (*free_fn)(void *ptr); MK> byte blk[]; MK> } memblk_t; MK> void efree_impl(void *ptr) MK> { MK> ... MK> } MK> void pefree_impl(void *ptr) MK> { MK> free(ptr); MK> } MK> void *pemalloc_impl(size_t sz) MK> { MK> return malloc(sz); MK> } MK> void *pemalloc(size_t sz, int persistent) MK> { MK> void *ptr; MK> if (persistent) { MK> ptr = emalloc_impl(sz + sizeof(memblk_t)); MK> ptr->free_fn = efree_impl; MK> } else { MK> ptr = pemalloc_impl(sz + sizeof(memblk_t)); MK> ptr->free_fn = pefree_impl; MK> } MK> return (void *)ptr->blk; MK> } MK> void efree(void *ptr) MK> { MK> memblk_t *actual_head; MK> actual_head = (memblk_t *)((byte *)ptr - &((memblk_t *)0)->blk); MK> actual_head->free_fn((void *)actual_head); MK> } MK> 2. Add some new constructors / destructors dedicated to the persistent MK> zvals, like ALLOC_INIT_PERSISTENT_ZVAL(), persistent_zval_dtor(), or MK> persistent_zval_ptr_dtor(). I don't like this idea though. MK> Any opinions? MK> Moriyoshi
-- Best regards, Marcus mailto:helly@php.net

Moriyoshi Koizumi

23 years ago
Hi Marcus, marcus.boerger@t-online.de (Marcus Börger) wrote:
> Hello Moriyoshi, > > to me that sounds good.
Actually I wasn't asking people to say aye or nay.. :) and at this moment I've got no ZE karma either. BTW I forgot to mention that part of my concern is backwards compatibility for both binaries and sources. Moriyoshi

(Marcus Börger)

23 years ago
Hello Moriyoshi, Tuesday, July 1, 2003, 8:08:04 PM, you wrote: MK> Hi Marcus, MK> marcus.boerger@t-online.de (Marcus Börger) wrote:
>> Hello Moriyoshi, >> >> to me that sounds good.
MK> Actually I wasn't asking people to say aye or nay.. :) and at this moment MK> I've got no ZE karma either. BTW I forgot to mention that part of my MK> concern is backwards compatibility for both binaries and sources. Anyway, you need to provide a patch to let us see and test. Best regards, Marcus mailto:helly@php.net

Moriyoshi Koizumi

23 years ago
marcus.boerger@t-online.de (Marcus Börger) wrote:
> Anyway, you need to provide a patch to let us see and test.
Well, I've wanted more feedbacks regarding this issue as it can well be a drastic change, and a few more engine guys would show interests than in stuff like i18n... Leave this task to me then. Moriyoshi