# Thread safe problem on module_registry (Zend API Feature/Change request)

- Thread: https://externals.io/message/28196
- Original archive: https://news-web.php.net/php.internals/28196
- Started by Michael Vergoz on 2007-03-01T13:29:25+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #28196 — Michael Vergoz — 2007-03-01T13:29:25+00:00

URL: https://externals.io/message/28196#28196

Hi
I am currently developing a kind of application server based on PHP
language.
I use modifications I made on SAPI embed/.
I use threads massively.

In my application design, every thread can load different PHP modules. In
practise, modules are loaded just before php_request_startup() and they are
unloaded after php_request_shutdown()

The problem I face is that I randomly receive PHP warnings :
<br />
<b>Warning</b>:  Module 'X7V3' already loaded in <b>Unknown</b> on line
<b>0</b><br />
<br />
<b>Warning</b>:  Function registration failed - duplicate name -
XXXXXXXXXXXXXXXXXX in <b>Unknown</b> on line <b>0</b><br />
<br />
<b>Warning</b>:  X7V3:  Unable to register functions, unable to load in
<b>Unknown</b> on line <b>0</b><br /

I looked at Zend/zend_API.c and I realized that 2 variables, "module_count"
and "module_registry", are not thread safe and that there is a comment
recomending mutex use for these 2 variables.

I had asked for a Feature/Change request on bugs.php.net (#40668) but it has
been closed :s

Then I learnt (thank you Tony) that `dl()` function is deactivated in  ZTS
mode and I also learnt from Tony that this kind of problem was not a
priority ...

I think it is important to settle this problem at least for IIS and Apache
Threadpool/Worker servers.

At last, I would like to share my view on ZTS vs mutex use :

Mutex :
pros : uses slightly less memory
cons : does not give possibility to create module spaces by thread - uses
more processor resource (as there is a mutualized lock for various threads)

ZTS :
pros : possibility to create module spaces - less processor
cons : slight impact on memory

This is why I propose to use a ZTS resource instead of mutex to make
"module_registry" thread safe.

The use of ZTS resources will give a thread the ability to have its own
module HashTable.

In both cases (mutex or ZTS resource), we will be able to reactivate the
 `dl()` function in ZTS mode.

I propose to develop the ZTS version resource. Or shall I let you do it ?

Kind regards

Michael Vergoz

---

## #28198 — Richard Lynch — 2007-03-01T22:06:10+00:00

URL: https://externals.io/message/28196#28198 · In reply to: #28196

I don't claim to understand this issue fully/deeply, but I'm
definitely +1 on resurrecting 'dl' if this change fixes everything to
everyone's satisfaction.

Not that my vote actually counts, as I've never had the skills/time to
actually contribute C code to PHP.

I may be the only user on the planet with a shared host that lets me
use 'dl' to pull in extensions, but there it is, and I kinda need it,
as there are no other viable options to do what I need to do, other
than changing to a new webhost I might not like... :-)

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

---

## #28227 — Edin Kadribasic — 2007-03-04T19:01:20+00:00

URL: https://externals.io/message/28196#28227 · In reply to: #28196

Hi Michael,

Making `dl()` work on threaded platforms would be nice. Illustrating your
idea with a patch would be very helpful.

Edin


Michael Vergoz wrote:
> Hi
> I am currently developing a kind of application server based on PHP
> language.
> I use modifications I made on SAPI embed/.
> I use threads massively.
> 
> In my application design, every thread can load different PHP modules. In
> practise, modules are loaded just before php_request_startup() and they are
> unloaded after php_request_shutdown()
> 
> The problem I face is that I randomly receive PHP warnings :
> <br />
> <b>Warning</b>:  Module 'X7V3' already loaded in <b>Unknown</b> on line
> <b>0</b><br />
> <br />
> <b>Warning</b>:  Function registration failed - duplicate name -
> XXXXXXXXXXXXXXXXXX in <b>Unknown</b> on line <b>0</b><br />
> <br />
> <b>Warning</b>:  X7V3:  Unable to register functions, unable to load in
> <b>Unknown</b> on line <b>0</b><br /
> 
> I looked at Zend/zend_API.c and I realized that 2 variables, "module_count"
> and "module_registry", are not thread safe and that there is a comment
> recomending mutex use for these 2 variables.
> 
> I had asked for a Feature/Change request on bugs.php.net (#40668) but it has
> been closed :s
> 
> Then I learnt (thank you Tony) that `dl()` function is deactivated in  ZTS
> mode and I also learnt from Tony that this kind of problem was not a
> priority ...
> 
> I think it is important to settle this problem at least for IIS and Apache
> Threadpool/Worker servers.
> 
> At last, I would like to share my view on ZTS vs mutex use :
> 
> Mutex :
> pros : uses slightly less memory
> cons : does not give possibility to create module spaces by thread - uses
> more processor resource (as there is a mutualized lock for various threads)
> 
> ZTS :
> pros : possibility to create module spaces - less processor
> cons : slight impact on memory
> 
> This is why I propose to use a ZTS resource instead of mutex to make
> "module_registry" thread safe.
> 
> The use of ZTS resources will give a thread the ability to have its own
> module HashTable.
> 
> In both cases (mutex or ZTS resource), we will be able to reactivate the
> `dl()` function in ZTS mode.
> 
> I propose to develop the ZTS version resource. Or shall I let you do it ?
> 
> Kind regards
> 
> Michael Vergoz

---

## #28242 — Michael Vergoz — 2007-03-05T13:12:53+00:00

URL: https://externals.io/message/28196#28242 · In reply to: #28198

Hello,

I made a patch that "mutex'ed" module_registry and module_count.
For the moment it doesn't solve the `dl()`.

The patch for last CVS PHP_5_2
http://mykii.binarysec.com/PHP/module_registry_mutex/module_register_mutex.patch

Small description :
http://mykii.binarysec.com/PHP/module_registry_mutex/readme.txt

Regards,
Michael Vergoz

----- Original Message ----- 
From: "Richard Lynch" <ceo@l-i-e.com>
To: "Michael Vergoz" <mv@binarysec.com>
Cc: <internals@lists.php.net>
Sent: Thursday, March 01, 2007 11:06 PM
Subject: Re: [PHP-DEV] Thread safe problem on module_registry (Zend API 
Feature/Change request)


> 
>
> I don't claim to understand this issue fully/deeply, but I'm
> definitely +1 on resurrecting 'dl' if this change fixes everything to
> everyone's satisfaction.
>
> Not that my vote actually counts, as I've never had the skills/time to
> actually contribute C code to PHP.
>
> I may be the only user on the planet with a shared host that lets me
> use 'dl' to pull in extensions, but there it is, and I kinda need it,
> as there are no other viable options to do what I need to do, other
> than changing to a new webhost I might not like... :-)
>
> -- 
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some starving artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?

---

## #28280 — Wez Furlong — 2007-03-07T06:09:06+00:00

URL: https://externals.io/message/28196#28280 · In reply to: #28242

Just curious, why did you choose to mutex around a hash instead of
using the zend_ts_hash functions?

Changing the access semantics while preserving the type and name of
that variable will cause any external modules that are unaware of that
change to subtly break, or if you're lucky, crash hard.

Seems "better" to make that break a little bit more obvious by
changing the name, or introducing an API to encapsulate the correct
access semantics.

These are just suggestions.  My main comments are that the locking
macros are mildly ugly and that a lack of compile time enforcement on
the new locking requirement will cause people pain with modules
outside of the main php distribution.

--Wez.




> Hello,
>
> I made a patch that "mutex'ed" module_registry and module_count.
> For the moment it doesn't solve the `dl()`.
>
> The patch for last CVS PHP_5_2
> http://mykii.binarysec.com/PHP/module_registry_mutex/module_register_mutex.patch
>
> Small description :
> http://mykii.binarysec.com/PHP/module_registry_mutex/readme.txt
>
> Regards,
> Michael Vergoz
>
> ----- Original Message -----
> From: "Richard Lynch" <ceo@l-i-e.com>
> To: "Michael Vergoz" <mv@binarysec.com>
> Cc: <internals@lists.php.net>
> Sent: Thursday, March 01, 2007 11:06 PM
> Subject: Re: [PHP-DEV] Thread safe problem on module_registry (Zend API
> Feature/Change request)
>
>
> > […]

---

## #28284 — Michael Vergoz — 2007-03-07T07:44:30+00:00

URL: https://externals.io/message/28196#28284 · In reply to: #28280

Hello Wez,

Thanks for your feedback.
Indeed the mutex that i placed isn't useful and in fact this is a test patch 
i made.
I didn't know TsHashTable :)
This says the mutex will not solve the problem to which i face.
The `dl()` function can't work with ZTS.

I coded other test source here :
http://mykii.binarysec.com/PHP/Zend_API_module_registry_TSRM/first_shot.patch

In fact the problem is deeper because there are other complex links as 
list_destructors that isn't TS whereas this one is used for the management 
of modules.

The design of construction and destruction of the modules aren't adapted to 
TS environment.

I think it's necessary to redesign the Modular aspect of PHP in order to 
solve these problems in-depth.

I have some ideas about this subject but my time is very restricted.

I propose to return to see you when I would have a serious proposal.

Regards,
Michael Vergoz

----- Original Message ----- 
From: "Wez Furlong" <kingwez@gmail.com>
To: "Michael Vergoz" <mv@binarysec.com>
Cc: <ceo@l-i-e.com>; <internals@lists.php.net>
Sent: Wednesday, March 07, 2007 7:09 AM
Subject: Re: [PHP-DEV] Thread safe problem on module_registry (Zend API 
Feature/Change request)


> Just curious, why did you choose to mutex around a hash instead of
> using the zend_ts_hash functions?
>
> Changing the access semantics while preserving the type and name of
> that variable will cause any external modules that are unaware of that
> change to subtly break, or if you're lucky, crash hard.
>
> Seems "better" to make that break a little bit more obvious by
> changing the name, or introducing an API to encapsulate the correct
> access semantics.
>
> These are just suggestions.  My main comments are that the locking
> macros are mildly ugly and that a lack of compile time enforcement on
> the new locking requirement will cause people pain with modules
> outside of the main php distribution.
>
> --Wez.
>
>
>
> 
> > […]