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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
