Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28196
Return-Path: <mv@binarysec.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 13211 invoked by uid 1010); 1 Mar 2007 13:45:30 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 13179 invoked from network); 1 Mar 2007 13:45:30 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 1 Mar 2007 13:45:30 -0000
Received: from [127.0.0.1] ([127.0.0.1:12013])
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ECSTREAM
	id E6/76-07629-7F8D6E54 for <internals@lists.php.net>; Thu, 01 Mar 2007 08:45:28 -0500
Authentication-Results: pb1.pair.com header.from=mv@binarysec.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=mv@binarysec.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain binarysec.com from 193.27.78.88 cause and error)
X-PHP-List-Original-Sender: mv@binarysec.com
X-Host-Fingerprint: 193.27.78.88 unknown Linux 2.5 (sometimes 2.4) (4)
Received: from [193.27.78.88] ([193.27.78.88:40007] helo=binarysec.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 76/65-07629-375D6E54 for <internals@lists.php.net>; Thu, 01 Mar 2007 08:30:29 -0500
Received: from michaelb651094 (unknown [172.16.2.1])
	by binarysec.com (Postfix) with SMTP id 61E2018C3
	for <internals@lists.php.net>; Thu,  1 Mar 2007 15:33:56 +0100 (CET)
Message-ID: <008c01c75c05$b6584ae0$070110ac@michaelb651094>
To: <internals@lists.php.net>
Date: Thu, 1 Mar 2007 14:29:25 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0086_01C75C0E.02E0C150"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Subject: Thread safe problem on module_registry (Zend API Feature/Change request)
From: mv@binarysec.com ("Michael Vergoz")

------=_NextPart_000_0086_01C75C0E.02E0C150
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 
------=_NextPart_000_0086_01C75C0E.02E0C150--