Re: [PHP4BETA] Modularization and Thread Safety

Zeev Suraski wrote: > > First, Stig - great job! With all of the modifications we've made in PHP > 4.0 (your directory restructure and automake/autoconf work, the way each > module takes care after its own globals and INI entries) it really > doesn't seem far before loadable modules are as easy to use as built-in > ones. Is there still serious work pending on this front? I think the only thing remaining is to generate the php3_builtin_modules array. This is not much work and will be handled by the PHP_EXTENSION macro, so no changes are necessary to the extensions themselves. We still have some dependency problems by the way. A good way of testing this is to do "make clean; make -j2". > About thread safety, in the last three days I worked a lot on getting > thread safety working again, and improved it. I've pretty much finished > my thread-safe resource manager, which is loosely based on Shane's idea > (it's pretty much a very quick implementation, that features a bit more > functionality). So far, a single threaded thread-safe php.exe runs > through just as reliably as the thread-unsafe one. The thread safe > resource manager sorts out the basic problems we've bumped into with TLS. > It allocates the necessary thread local storage just-in-time; Optionally > initializes it using a constructor function; Optionally destroyes it > using a destructor function; works fine from within DLLs; and completely > portable You can get a good example as to how to work with this thread > safe resource manager (tsrm) by looking the the MySQL module - look at the > definitions in php3_mysql.h (look for ZTS), and the mysql.c source. I did an honest attempt to make the odbc extension thread safe, but as usual it is not tested. :-) Could you take a look at the code and see if it looks ok? > You can check out tsrm from :pserver:cvs.zend.com:/repository/TSRM. > > Also, for those of you who were involved in the PHP 3.1 thread safety > effort, you may recall that an annoying problem was the fact that > flex-generated scanners are not reentrant and not thread safe, and fixing > that required actually patching flex.exe itself. Zend's design made it a > hell of a lot easier, or at all feasible, to use Flex's C++ scanner class. > Yesterday, I've successfully modified Zend to compile the scanner as a C++ > class when compiling for thread safety, and a standalone scanner object is > usef for every scanning job. It ended up being very efficient (no TLS > lookups) and very very clean. The thread unsafe project compiles the > scanner as a regular C scanner. > > By the way, as you probably understood, we've decided that a C++ compiler > would be absolutely necessary to compile libzend as a thread safe library. I don't have any problems with that. When we get the thread safety going, perhaps it is time to contact the Zeus people again? I bet they are easily convinced to write ISAPI support that works for both IIS and Zeus. ;-) - Stig -- PHP 4 Beta