Everything

php

php_module_startup: more than one additional_module impossible?

php.internals

Norbert Wagner

21 years ago

Hi,

I need to load more than one "additional_module" in my self-made
SAPI-module.

Looking around at the php/zend-API, I thought that the
php_module_startup(...) function provides such functionality:

int php_module_startup(sapi_module_struct *sf, zend_module_entry
*additional_modules, uint num_additional_modules)

But then, It looks to me that the *additional_modules - parameter is
lacking an indirection: Shouldn't it be **additional_modules or
*additional_modules[] instead?

As long as you try to register only one additional module (which is what
all the other SAPI-Modules do that I have found), everything is fine.
But I'd like to register an arbitrary number of modules during startup
without reading php.ini.

Any Ideas? I am quite new to PHP, perhaps I have just missed the spot?

Regards,
Norbert

Wez Furlong

21 years ago

You might be right about that.
The current prototype does allow this though:

zend_module_entry modules[2] = {
{ ... first module ... },
{ ... second module ... }
};

php_module_startup(&sapimodule, modules, sizeof(modules)/sizeof(modules[0]));
There are other ways to fire up additional modules dynamically; take a
look at the code in ext/standard/dl.c to see how the dl() function
(and "extesion=" init statement) works.

--Wez.

On Fri, 10 Sep 2004 22:55:18 +0200, Norbert Wagner
<nw@softwarekombinat.de> wrote:

Norbert Wagner

21 years ago

Hi,

thank's for your answer!

Wez Furlong wrote:

> You might be right about that.
> The current prototype does allow this though:
>
> zend_module_entry modules[2] = {
> { ... first module ... },
> { ... second module ... }
> };
>
> php_module_startup(&sapimodule, modules, sizeof(modules)/sizeof(modules[0]));

That won't work, I fear, because php_module_startup() passes &modules to
php_startup_extensions(), which iterates of it the "normal" way.
You need zend_module_entry** - parameter for this to work properly :-(

> There are other ways to fire up additional modules dynamically; take a
> look at the code in ext/standard/dl.c to see how the dl() function
> (and "extesion=" init statement) works.

I tried to call php_dl() directly, but this functions doesn't get
exported. Then I tried to invoke dl() via call_user_function(), but this
also failed - probably because I need a request context to do this (?).
My next thought was to copy php_dl() and load the extensions by hand
after php_module_startup(), but this didn't succeed, either: I saw my
modules via get_loaded_extensions(), but my classes did not get
registered correctly (They were simply not declared in "script-space").
Perhaps the sequence in  php_module_startup() is essential here, I don't
know...

A solution might be to add a new php_module_startup_ex(...) function
with the right parametes, and let php_module_startup() be a wrapper
around it.
At least this would keep existing SAPI-modules working:



/* {{{ php_module_startup
*/
int php_module_startup(sapi_module_struct *sf, zend_module_entry
*additional_modules, uint num_additional_modules)
{
return php_module_startup_ex(
sf, &additional_modules, num_additional_modules );
}


/* {{{ php_module_startup_ex
*/
int php_module_startup_ex(sapi_module_struct *sf, zend_module_entry
**additional_modules, uint num_additional_modules)
{
/* old php_module_startup() body here */
}



What do you think?

Regards,
Norbert

Unnamed Person

21 years ago

> -----Original Message-----
> From: Norbert Wagner [mailto:nw@softwarekombinat.de]
>
> Perhaps the sequence in  php_module_startup() is essential here, I don't
> know...

You must have ZTS defined, yes?  I've had the same problem.  It has
something to do with the zend_post_startup() call in php_module_startup().
This also precludes a manual call to php_startup_extensions() from
working.  :-(

> A solution might be to add a new php_module_startup_ex(...) function
> with the right parametes, and let php_module_startup() be a wrapper
> around it.
> At least this would keep existing SAPI-modules working:
>
>
> /* {{{ php_module_startup
>   */
> int php_module_startup(sapi_module_struct *sf, zend_module_entry
> *additional_modules, uint num_additional_modules)
> {
>      return php_module_startup_ex(
>          sf, &additional_modules, num_additional_modules );
> }
>
>
> /* {{{ php_module_startup_ex
>   */
> int php_module_startup_ex(sapi_module_struct *sf, zend_module_entry
> **additional_modules, uint num_additional_modules)
> {
>   /* old php_module_startup() body here */
> }
>
> What do you think?

My opinion...your solution clearly achieves your desired goal.
However, I don't like the idea of leaving php_module_startup with
a broken interface.  Since only one module would work, the
num_additional_modules param is misleading.  I'd rather fix
the bug and have folks patch their code to the new face
(there ain't that many callers, and it's a trivial fix).
Course, I have no authority in the matter ;-)

Additionally, it is strange to me that we can't call
php_startup_extensions() at app init time after having called
php_module_startup().  But I don't understand the engine design
enough to know if that is prudent.

NOTE: I think it is also possible that if you add your custom
extension to the php/ext directory that the build scripts will
automatically pickup your extension and add its zend_module_entry
to the generated main/internal_functions.c file.  Checkout
http://www.zend.com/apidoc/zend.build.php for more info.

Cheers,
-Scott

Norbert Wagner

21 years ago

saguyer@gte.net wrote:
[...]

>
>>A solution might be to add a new php_module_startup_ex(...) function
>>with the right parametes, and let php_module_startup() be a wrapper
>>around it.
>>At least this would keep existing SAPI-modules working:
>>
>>
>>/* {{{ php_module_startup
>>  */
>>int php_module_startup(sapi_module_struct *sf, zend_module_entry
>>*additional_modules, uint num_additional_modules)
>>{
>>     return php_module_startup_ex(
>>         sf, &additional_modules, num_additional_modules );
>>}
>>
>>
>>/* {{{ php_module_startup_ex
>>  */
>>int php_module_startup_ex(sapi_module_struct *sf, zend_module_entry
>>**additional_modules, uint num_additional_modules)
>>{
>>  /* old php_module_startup() body here */
>>}
>>
>>What do you think?
>
>
>
> My opinion...your solution clearly achieves your desired goal.
> However, I don't like the idea of leaving php_module_startup with
> a broken interface.  Since only one module would work, the
> num_additional_modules param is misleading.  I'd rather fix
> the bug and have folks patch their code to the new face

You are right. Having a clear interface is probably more important than
short-term reduction of work for a few developers.

> (there ain't that many callers, and it's a trivial fix).
> Course, I have no authority in the matter ;-)

> Additionally, it is strange to me that we can't call
> php_startup_extensions() at app init time after having called
> php_module_startup().  But I don't understand the engine design
> enough to know if that is prudent.

Yup. A useable php_startup_extensions() would sure be nice. Currently a
working php_module_startup() would be sufficient for me, though ;-)

>
> NOTE: I think it is also possible that if you add your custom
> extension to the php/ext directory that the build scripts will
> automatically pickup your extension and add its zend_module_entry
> to the generated main/internal_functions.c file.  Checkout
> http://www.zend.com/apidoc/zend.build.php for more info.

In my case, the PHP extensions are part of a bigger picture and
recompiling PHP would not fit very well in existing build processes.
We are uing PHP to provide a web-based interface to a server software
written in C++. So the "core part" is the C++ software here...

Anyway, is there anything I can do to get this fixed in CVS?
Would a patch have a chance to be applied?

Regards,
Norbert