Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Walter Franzini [EMAIL PROTECTED]] [sorry, my English is bad] Zeev Suraski [EMAIL PROTECTED] writes: [...] Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev An example not solvable using php.ini: At SysNet, we access dbms only with odbc_* functions using (for different apps on the same server) solid and IBMdb2. We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the right module using dl (). Using php.ini is not feasible because this lead to multiple function definition. I think a similar situation may arise with multiple xslt backend, they must export the same API but could provide different features (or bugs) so you must use xslt1 for app1 and xslt2 for app2. Please don't drop dl () :-) Shane Caraveo did some work on the ODBC module to solve this once, by using macros for all potentially clashing symbols in the ext/odbc source. It's not there anymore though, and that's mostly my fault. I guess we could go back to that model. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 11:37 28-08-01, Walter Franzini wrote: [sorry, my English is bad] Zeev Suraski [EMAIL PROTECTED] writes: [...] Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev An example not solvable using php.ini: At SysNet, we access dbms only with odbc_* functions using (for different apps on the same server) solid and IBMdb2. We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the right module using dl (). Using php.ini is not feasible because this lead to multiple function definition. I think a similar situation may arise with multiple xslt backend, they must export the same API but could provide different features (or bugs) so you must use xslt1 for app1 and xslt2 for app2. Please don't drop dl () :-) We're not dropping it :) It works just as well as it did until now, which is not too well. Solving the problems that arise by deprecating dl() (improving the ODBC module, for instance) are much easier than solving the problems that fixing the broken things about dl(). Right now, we're simply keeping the status-quo. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 10:39 08-08-01, Thies C. Arntzen wrote: On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... Right. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 09:39 AM 8/8/2001 +0200, Thies C. Arntzen wrote: On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... Yeah I also remember it didn't give us anything. I think the most notably impact with shared libraries is the load time of the shared library itself. It is not significant in the web environment though when PHP is compiled as a server extension module. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
I haven't run into problems with it yet, but I'll keep this in mind, I
guess.
-Andrei
* http://www.zend.com/comm_person.php?id=24 *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
I disagree, is there any way dl() can be fixed, because it is a useful function... On Mon, 06 Aug 2001, Zeev Suraski wrote: At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Zeev At 17:55 06/08/2001, Andy wrote: I disagree, is there any way dl() can be fixed, because it is a useful function... On Mon, 06 Aug 2001, Zeev Suraski wrote: At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
See my letter to Andrei. I've yet to see an ISP that (knowingly) allows users to load extensions, and wouldn't agree to add them to the php.ini file. This isn't a case of me saying users don't need X or 95.6% of the scripts out there don't need Y. This is me saying that dl() is *bad*, even if people got used to using it, which is why it should be deprecated. Again, notice that it has been deprecated for a long while in thread-safe mode, which means people who develop under Windows (a huge share) don't have it for over a year. dl() is bad in pretty much every sense, including the new sense you mentioned in your letter - dl()'ing extensions in a shared environment. Forcing the ISP to admit any extensions into the php.ini file before it gets loaded to the server is a good thing. If dl() is one of PEAR's foundations, it's time to dig it up and replace it with something more sound and stable :) Using php.ini for loading extensions should be the way to go. Zeev At 18:18 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote: don't think there's an API for that. we would have to add the MODULE_NUMBER to the class-entry and then (when unloading the module) also destroy the classes that that module defined. i think constants and functions already do this. Hmm, right, they don't have module_number.. -Andrei * Why is it always Segmentation's fault? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 06:30 06/08/2001, Sterling Hughes wrote: On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. Also, just to mention, right now it might not be that big a deal to load them all in php.ini (well something as big PHP-GTK would be, but...), however, as PHP gets more and more extensions written in C, there needs to be this functionality. Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? -Andrei * Life may be expensive, but it includes an annual free trip around the sun. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) -Andrei * Marriage is not a word. It's a sentence. Life-long sentence. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:45 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) :) Anyway, I'm off for a few hours now, reinstalling my machine. I'll answer anything that comes up when I get back ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: I think the disk weights about the same regardless of the data inside it :) Yes, but 50 extensions will consume more memory than 1. -Andrei In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
Hi, Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. I agree with you when we are talking about using PHP in a webserver. However, I am seeing more and more use of PHP as a generic scripting language. In this situation, I think dl() is very useful... Imagine a application written in PHP that has a 'special' extension. For example, an extension to access a scanner. You don't want this loaded everywhere, just in your scanner application, and certainly not in your webserver. In a few words: For a webserver: ban dl() For generic scripting: keep dl() Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
In a few words: For a webserver: ban dl() For generic scripting: keep dl() What's really the point of protecting people from their stupidity. If you're going to keep it in the generic scripting engine (which I think has lots of value), why not keep it in the webserver engine as well. There are plenty of php extensions which, imho, operate way to slow to called on a busy production site. Does that mean they should be eliminated? No, it means they should just be used with a 'buyer-beware' mentality. George -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 23:57 06-08-01, Sander Steffann wrote: Hi, Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. I agree with you when we are talking about using PHP in a webserver. However, I am seeing more and more use of PHP as a generic scripting language. In this situation, I think dl() is very useful... Imagine a application written in PHP that has a 'special' extension. For example, an extension to access a scanner. You don't want this loaded everywhere, just in your scanner application, and certainly not in your webserver. You can achieve the same goal using a command line entry. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
I disagree in two levels. First, I think that saying We can't protect people from their stupidity, so let's lift all bars is just plain wrong and a bad approach in a real world situation. Sure, it's true, but we can definitely reduce the risks involved in common mistakes that people make. Not bulletproof, but sometimes simply hinting people not to go around places where shots are fired is good enough. On the second level, there are several other reasons not to keep dl() which aren't related to security or preventing people from doing the wrong things. These are: - Slow performance, encourages slow app writing - Complicates the development of extensions and the engine - Will not work in thread safe mode All in all, dl() is simply bad, in just about every level. Zeev At 00:03 07-08-01, George Schlossnagle wrote: In a few words: For a webserver: ban dl() For generic scripting: keep dl() What's really the point of protecting people from their stupidity. If you're going to keep it in the generic scripting engine (which I think has lots of value), why not keep it in the webserver engine as well. There are plenty of php extensions which, imho, operate way to slow to called on a busy production site. Does that mean they should be eliminated? No, it means they should just be used with a 'buyer-beware' mentality. George -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
