CVS update: php31

Date: Wednesday September 9, 1998 @ 7:59 Author: ssb Update of /repository/php31 In directory asf:/u2/tmp/cvs-serv10651 Modified Files: function_modules.txt Log Message: formatting Index: php31/function_modules.txt diff -c php31/function_modules.txt:1.2 php31/function_modules.txt:1.3 *** php31/function_modules.txt:1.2 Thu Sep 3 10:57:11 1998 --- php31/function_modules.txt Wed Sep 9 07:59:48 1998 *************** *** 1,46 **** Moving function modules/extensions from 3.0 to 3.1 ! The function module api, as of Sept 3, 98, has not changed. A 3.0 module ! should compile with minimal changes in the preprocessor includes. I have ! started to make a practice of useing the define PHP_31 to decide where to ! get included files from, so as to keep the modules compilable with 3.0. There ! are a few things that have to be done to make the module cross-platform ! compilable, and should be done as general practice, unless the module will ! never be compilable on windows (for instance the c library is simply not ! available there). They are: ! ! * add the define IS_EXT_MODULE as the very first define in the source file, ! for any module that is intended to be compiled as either a static or a ! dynamic module. This define forces the module to use the PHPAPI for i/o ! operations, rather than making the calls directly. * rewrite any references to php3_ini to use calls to cfg_get_*() (in configuration_parser.c. ! * rewrite any references to GLOBAL() variables. PHP internal global varibales ! are not accessable from a dynamicly loadable module. I have not seen any ! modules yet that have to have internal globals, but if so, we can write a ! callback function to get it. That would at least maintain usability as a ! dynamic module. ! ! function module thread safety issues ! ! Note, in 3.1 there is a set of defines used for thread safety located in php3_threads.h. ! ! All globals and static vars should be placed into a struct for that module. In ! the module startup and shutdown functions, code must exist to create a TLS index ! for the module. Also, NAME_TLS_VARS and NAME_GLOBAL must be defined (NAME being ! replaced with some unique reference to the module. Reference ! unified_odbc.c or mysql.c for examples of how this is done. Also reference ! php3_threads.h/c for more information. Unix thread safety is actualy not as far off ! as you may think. The MS TLS api is very close to the pthreads TLS functions, and ! can almost (not quite) be directly mapped via defines. We just need someone ! who is used to using pthread tls develop and test it. ! ! ! Ported modules ! ! These modules have been ported to 3.1, and backported to 3.0. If they are not patched ! in the 3.1 tree, we should be able to now just move them over from 3.0 and have them ! work just fine. ldap zlib --- 1,51 ---- Moving function modules/extensions from 3.0 to 3.1 ! The function module api, as of Sept 3, 98, has not changed. A 3.0 ! module should compile with minimal changes in the preprocessor ! includes. I have started to make a practice of useing the define ! PHP_31 to decide where to get included files from, so as to keep the ! modules compilable with 3.0. There are a few things that have to be ! done to make the module cross-platform compilable, and should be done ! as general practice, unless the module will never be compilable on ! windows (for instance the c library is simply not available there). ! They are: ! ! * add the define IS_EXT_MODULE as the very first define in the source ! file, for any module that is intended to be compiled as either a ! static or a dynamic module. This define forces the module to use ! the PHPAPI for i/o operations, rather than making the calls ! directly. * rewrite any references to php3_ini to use calls to cfg_get_*() (in configuration_parser.c. ! * rewrite any references to GLOBAL() variables. PHP internal global ! varibales are not accessable from a dynamicly loadable module. I ! have not seen any modules yet that have to have internal globals, ! but if so, we can write a callback function to get it. That would ! at least maintain usability as a dynamic module. ! ! Function module thread safety issues: ! ! Note, in 3.1 there is a set of defines used for thread safety located ! in php3_threads.h. ! ! All globals and static vars should be placed into a struct for that ! module. In the module startup and shutdown functions, code must exist ! to create a TLS index for the module. Also, NAME_TLS_VARS and ! NAME_GLOBAL must be defined (NAME being replaced with some unique ! reference to the module. Reference unified_odbc.c or mysql.c for ! examples of how this is done. Also reference php3_threads.h/c for ! more information. Unix thread safety is actualy not as far off as you ! may think. The MS TLS api is very close to the pthreads TLS ! functions, and can almost (not quite) be directly mapped via defines. ! We just need someone who is used to using pthread tls develop and test ! it. ! ! ! Ported modules: ! ! These modules have been ported to 3.1, and backported to 3.0. If they ! are not patched in the 3.1 tree, we should be able to now just move ! them over from 3.0 and have them work just fine. ldap zlib -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net