Arvind Srinivasan wrote:
>> Does the GLOBALS_ID_BASE idea work? In
>> "ts_allocate_reserved_id(GLOBALS_ID_BASE+1...)" each extension would
>> anyway need to reserve an increment to avoid clashes. Also, why is
>
> I didn't really try using this. When I added it, I thought it might be
> useful for modules that live outside the PHP source tree. They could
> then define their constants using
> #define FOO_ID (GLOBALS_ID_BASE + 3)
> rather than hardcoding 33. As you point out, they would still need to
> reserve an increment.
>
>> GLOBALS_ID_BASE 30 when the largest reserved value is 18? Maybe I'm
>> missing something.
>>
> I reserved IDs for the subsystems I thought were core. I was sure
> there'd be others that I'd missed and so I left space for more.
>
>
>> Would there be significant memory space or locality issues if one ID
>> per extension in the PHP source bundle was reserved upfront, even if
>> those extensions were never enabled?
>>
>
> I'll run some tests and see what impact this has.
I'd vote that the reserved slots be assigned from day 1 for one of (i)
always-enabled core extensions or (ii) for core + common extensions or
{iii} the whole set of PHP-bundled extensions + common extensions from
PECL (i.e. APC?). The choice of (i), (ii) or (iii) would depend on
your tests.
All other extensions should use a run-time allocated non-reserved
slot. Extensions that become popular can add an xxx_GLOBALS_ID entry
to zend_globals_macros.h.
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
