Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <165e01c68be9$afb4cb60$6602a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Stanislav Malyshev" <stas@zend.com>
Cc: <internals@lists.php.net>
References: <000001c68af5$50876930$6e02a8c0@thinkpad><7B45819D-6E8D-4B9B-A02B-BC00BE6B1930@prohost.org> <7.0.1.0.2.20060608164415.06b4ae50@zend.com> <133f01c68b73$fb1a1bd0$6602a8c0@foxbox> <Pine.LNX.4.64.0606091127001.17284@mail.zend.com> <145901c68bad$cdd4b470$6602a8c0@foxbox> <Pine.LNX.4.64.0606091732500.306@mail.zend.com>
Date: Fri, 9 Jun 2006 19:25:20 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
From: steph@zend.com ("Steph Fox")


> 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 why is this conclusion.

Because we need to work through one resource at a time from the top, and 
because dl'd modules are the last things with a resource id to be loaded, 
because they have to be.

Do you suppose only modules allocate
> IDs and each of them allocates exactly one?

See my note to Dmitry - anything that allocates more than one resource is 
broken for shared loading anyway unless it frees it from its own MSHUTDOWN.

What about Zend extensions
> that also allocate IDs but do not have modules?

You got me there. OK, I didn't know that happens until just now. The rest is 
fine - really. But ... do Zend extensions actually use TSRM at all? - I 
looked at XDebug, it uses TSRM if it's loaded as a PHP module, but not in 
zend_extension mode. Is there some reason for that? Then the 
zend_extensions_startup_mechanism() inits the llist for extensions some way 
before the module registry kicks off. Doesn't that kind of imply that 
zend_extensions load before modules are registered? The zend_extension llist 
is destroyed _after_ the module registry is, which kind of backs up that 
theory. I should test it, but looking at what happens there - I don't see it 
causing problems.

> What about modules not needing globals?

I already went through that twice today...

>And what about dl()ed modules? Unless I am missing some
> cruicial bits, this assumption seems to me very dangerous one.

You're missing some crucial bits. You're assuming that the id that is freed 
is actually that module's id, for a start. It isn't, it's just the next id 
in the list - but only the number of dl'd modules is ever counted.

> SF>>Since dynamically loaded modules are the last ones to load, they're 
> the
>
> Are you sure they are? You can load an extension on another extension
> startup, for example. Or on module startup. Or on any other stage of
> startup procedure, for that matter, starting with module startup. You seem
> to be relying on very precise order of events for this to work, which is
> not guaranteed to happen.

The key there is 'starting with module startup'. For a start there are two 
distinct branches of module startup - the internal module startup, which 
only deals with built-in modules, and the module registry, which is where 
everything is actually loaded. You do actually need a core loaded to load 
those modules into - that particular aspect of the load order can't change. 
It's all about dependency - and that's exactly why the unload order _has_ to 
reflect it and reverse it.

> SF>>care about dl'd modules at this point. Nothing else actually needs its
> SF>>resource freeing before tsrm_shutdown() (which cleans up everything 
> that
>
> Zend extensions do too.

Yes, but since they're loading earlier than modules there's no impact there.

> SF>>list. But freeing a module's resources slightly early during shutdown
> SF>>doesn't do it any harm anyway - and the big thing here's to guarantee 
> the
>
> I don't like it at all. Really. If the code does not do what it was
> intended to do, it's no excuse to say "well, nothing really bad happened"
> - maybe not now, but what will happen in a year when another dozen of
> extensions arrives? If the code doesn't do exactly the clearly defined
> things it is supposed to do - we are literally inviting trouble for
> ourselves later on the way. I thin such code is way too dangerous.

You're misunderstanding me. The only thing that can happen is that the next 
module in the list has its resource_id freed near the end of a loop rather 
than at the start of the next loop. Because the count only considers dl'd 
modules, at worst that means a couple of the builtin extensions might get 
freed 'early' in that sense. Half of them already call ts_free_id() anyway - 
the impact of doing that is absolutely not negative.

The only thing in the equation I don't 100% know about and haven't tested is 
Zend extensions - I'm going on the code alone for that.

- Steph