#49686 [WFx]: SPL as a shared ext: run-time check for SPL instead of compile-time

From: Date: Mon, 28 Sep 2009 03:22:04 +0000
Subject: #49686 [WFx]: SPL as a shared ext: run-time check for SPL instead of compile-time
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-142972@lists.php.net to get a copy of this message
ID: 49686 User updated by: galaxy4public+php at gmail dot com Reported By: galaxy4public+php at gmail dot com Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.3.0 New Comment: What really concerns me in regard to SPL as a static extension is that many other extensions depends on it. For instance, with SPL statically linked into PHP it's not possible to build the PCRE extension as shared, and there more extensions which could have been dynamically built if SPL was allowed to be "shared". Consider the following scenario (we are currently running on our servers): we have a shared hosting environment with hundreds of virtual hosts and each additional unneeded extension consumes server's memory, hence we provide a very basic PHP interpreter with no extensions loaded. Then, users can load needed extensions vi their local php.ini or using dl(). That's why I'm trying to convince you that making "extensions" to be really extensions (i.e. dynamically loaded parts) is quite important. Previous Comments: ------------------------------------------------------------------------ [2009-09-28 03:05:13] galaxy4public+php at gmail dot com Actually the patch changes 2 lines in ext/array.c and makes it possible to build SPL as a shared extension (all other code is already in place). In 5.3.0 somebody removed a couple of configuration lines from ext/spl/config.m4 and made it impossible to configure SPL with the configure script. I believe that this was done due to the fact that calls to SPL are all hardcoded dependencies. Frankly, I don't understand why hardcode things when the mechanism for dynamic loading is already here. Instead of unconditionally rely on things like: === if (Z_OBJ_HT_P(array)->get_class_entry && instanceof_function(Z_OBJCE_P(array), spl_ce_Countable TSRMLS_CC)) { === why don't you use something like: === if (zend_hash_find(EG(class_table), "countable", sizeof("Countable"), (void **) &pce) == SUCCESS) { if (Z_OBJ_HT_P(array)->get_class_entry && instanceof_function(Z_OBJCE_P(array), *pce TSRMLS_CC)) { === Then, you can: a) drop '#ifdef HAVE_SPL' around this blocks, since they will no longer strictly depend on SPL; b) it will be possible to build/load SPL dynamically (with no or little effort) Otherwise, what's the point of having "extensions" if they aren't extensions but an integral part of the interpreter and can't be loaded dynamically? What really missing in PHP is a good extension dependency mechanism (and, perhaps, auto extension loading), IMHO. ------------------------------------------------------------------------ [2009-09-27 19:57:39] pajoye@php.net I think we can safely reject the patch. Unless someone has a strong argument to allow 5.2.12 to do not be forward compatible in some install (as in not having spl enabled :). ------------------------------------------------------------------------ [2009-09-27 19:35:27] scottmac@php.net SPL is force enabled with PHP 5.3+ as static, so this patch really only applies to 5.2 and I'm not sure if we're still open for new features. ------------------------------------------------------------------------ [2009-09-27 11:23:04] galaxy4public+php at gmail dot com Well, I made the directory world-readable: ftp://ftp.ru.openwall.com/pvt/galaxy/php-spl-shared/ I'll place any updates to the patch there (if there are any). ------------------------------------------------------------------------ [2009-09-27 10:37:23] galaxy4public+php at gmail dot com Ouch, this line-wrapping feature really hurts! :( In the comment above the link should be manually concatenated to get a correct URL. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49686 -- Edit this bug report at http://bugs.php.net/?id=49686&edit=1

« previous php.bugs (#142972) next »