[PHP-DEV] new apache fastcgi implementation and phpfastcgi patch
Why php cannot be able to be a real application server!? :) no, no, no i've not said that... :) ok... no really, separating static from dynamic serving are not in the logic of reverse proxy apache scheme handler implementation who serve by default all file from path to a backend... my solution work like ProxyPass apache proxy command: ProxyPass / fcgi://my.fscgi.server.com/ if you whant another implementation of apache fastcgi implementation like the old one who serve only file extension is not the way i've choose...sorry... I’ve made apache proxy scheme handler (like proxy module ftp or ajp) and is not apache handler or filter like mod_php or mod_fastcgi(the original one). this is a method to make apache module for the apache proxy infrastructure, and make possible to implement scheme handler hook that implement protocol handler like http: or ftp:. is the way I’ve used to implement the protocol scheme fcgi:. but with my code base I can be able make handler module like the original one without too much work... but i go to do that after I’ve resolve my need...the reverse proxy mode ! and if you have 100 or 200 php instances (and the same number of reverse proxy in front) to manage... and if you add one apache to each fastcgi server all multiply by 100-200 ... is more complicate to manage and consume more memory(apache processus+php fastcgi processus*100-200)... if i can suppress apache (or equivalent) in the equation of the php side i'm happy...more memory free to php fastcgi... and if i use apache in parallel to php fastcgi why not use directly apache + mod_php (and always the reverse proxy in front) and with apache + mod_php this solution consume less memory on php side than apache + fastcgi/php... and is more simple to configure than making apache (or other http solution) for static and php fastcgi for dynamics... my need is to make complete separation between apache and php. And making php a complete application server...like AJP implementation vs tomcat/jboss like... to make an only one architecture type with mixed application language... (php, tomcat, weblogic, websphere...) and separating static file vs using cache on reverse proxy for caching static content... in performance i thing is similar... and if is similar with separate it if is more simple manipulate...and administrate... but why why Best Regards, Mathieu _ From: James Aylett [mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], internals@lists.php.net Sent: Mon, 27 Nov 2006 08:35:05 +0100 Subject: Re: [PHP-DEV] Re: [EMAIL PROTECTED] RE: [PHP-DEV] new apache fastcgi implementation and phpfastcgi patch Further, if you're using apache 2 as your front end reverse proxy, you'll be fine running it as your backend static web server as well (in a different configuration); it's another instance, not a whole different app type to monitor. If your monitoring framework can do it in the first layer, it can do it in the second as well. The niche for static serving out of the fastcgi process would be where you want more security than one single web server, but you aren't into huge scaling issues where dynamic and static content will be managed separately. I'm not really convinced it's a big niche, though - if you aren't into huge scaling issues, you can just put a reverse proxy on the front of your existing web server to get close to the same effect (since security vulnerabilities in the second layer that are still exposed through the proxy are liable to be app errors rather than server bugs, so no amount of separation short of an HTTP-speaking proxy or filter is going to guard against this - at which point we're into a whole different territory of architecture). I agree with the general tone on this thread - while a better fastcgi implementation is great, it doesn't need to serve static files. I wouldn't use it for that. James -- James Aylett Chief Technical Architect t 020 7535 9850 f 020 7535 9900 w http://tangozebra.com/ Tangozebra may not be held responsible for the content of this email as it may reflect the personal view of the sender and not that of the company. Should you receive this email in error, please notify the sender immediately and do not disclose copy or distribute it. Tangozebra runs anti-virus software on all servers and workstations, and cannot be held responsible for any infected files that you may receive. Tangozebra advises all recipients to virus scan all emails, and to eat five portions of fruit and vegetable daily. -Original Message- From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED]; internals@lists.php.net internals@lists.php.net Sent: Mon Nov 27 05:40:15 2006 Subject: RE: [PHP-DEV] Re: [EMAIL PROTECTED] RE: [PHP-DEV] new apache fastcgi implementation and phpfastcgi patch I understand the thinking
Re: [PHP-DEV] Question on thread safety
Stanislav Malyshev wrote: So finally to my question. Is it the intention of TSRMc. to allow ts_allocate_id() to be called at any time or is there an unwritten rule that it should only ever called during php startup ? If its the former then I I think it gets called only on startup. I also think it was the intent, though there is no safeguard as far as I can see against calling it in run-time, but no module does it and it doesn't make sense to do it in other place than startup. I myself see no reason why extension writers should be restricted from calling ts_allocate_id() outside PHP startup so believe the code needs Well, the reason is that if you want to use TSRM globals, you have to allocate ID before you do basically anything with them. Startup is a good place for that. If you don't need globals, then you should not call it at all. The situation where in the mid-run you suddenly remember you need globals seems quite unrealistic to me. Of course, if you can describe scenario when you would really need it in mid-run or it would make sense to allocate ID in mid-run, then I guess this should be fixed or at least safeguarded. I did not have any particular scenario in mind here as I too could not come up with a sensible reason to allow calls to ts_allocate_id() outside initialization. Initially I thought of the case of a user script loading an extension using dl() but soon found out this is policed and not allowed if ZTS is enabled. The reason I assumed that ts_allocate_id() was designed to be called at any time was the fact that the code is wrapped in a mutex, which lead to my concerns about ts_resource_ex(). If ts_allocate_id() is not designed to be called outside startup then my concerns about ts_resource_ex() are unfounded. However, the mutex acquire and release calls in ts_allocate_id() are therefore unnecessary and should be removed. However, I do believe this restriction should be policed to fail any calls outside startup. I see nothing in the code to stop a extension writer calling ts_allocate_id at runtime. Why would anyone do this ? So TSRM global storage is only allocated when an extension is actually needed rather than when a new thread is started. What if a user has an extension that only gets called in some exceptional circumstance and they design it so the ts_allocate_id() call is made on the first call to the extension to save storage being allocated for threads until its needed. Unlikely I know but sometimes users do what you least expect so the code should protect them wherever possible from them doing something which will: (a) cause them grief, and (b) probably lead them into raising a bogus defect and waste someones time diagnosing the problem A simple check in the code could prevent all this. There are further routines in TSRM.c which also acquire the tsmm_mutex were the reason for this is not clear given current usage: * ts_free_id(). Only called at MSHUTDOWN when single threaded so no apparent need for mutex. Again easily policed to ensure calls outside startup/shutdown not allowed. * ts_free_worker_threads(): Only called by php_module_shutdown when single threaded so no need for mutex. * ts_resource_ex: Needs mutex whilst it updates tsrm_tls_table for a new thread but it looks like it keeps mutex longer than it need do. By reworking this routine and allocate_new_resource() I believe the time the mutex is held could be reduced. I am happy to work on a patch for all this and will raise a defect with patch when I have something worthy of consideration.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] thread unsafety inventory
On 27-Nov-06, at 3:24 PM, Ron Korving wrote: gmtime: (use gmtime_r) ext/interbase/ibase_query.c on line 679 Fixed. ext/pdo_sqlite/sqlite/src/date.c on line 948 (external code library) This code cannot be reached since we compile libsqlite with date functions. sapi/thttpd_patch on lines 282, 1355, 2298 External application patch, can't be helped. ctime: (use ctime_r) ext/mime_magic/mime_magic.c on line 1759 Fixed. localtime: (use localtime_r) ext/com_dotnet/com_variant.c on line 818 Win32 only code and there localtime is already thread-safe. ext/pdo_sqlite/sqlite/src/date.c on line 415 (external code library) ext/sqlite/libsqlite/src/date.c on line 419 (external code library) ext/xmlrpc/libxmlrpc/xmlrpc.c on line 234 (external code library) ext/zip/lib/zip_dirent.c on lines 398, 525 (external code library) Fixed. You may want to report the sqlite issues to sqlite devs so that they can apply a fix in their code base as well. sapi/thttpd_patch on line 2300 (external code library) External application patch, can't be helped. crypt: (use crypt_r) ext/standard/crypt.c on line 149 Fixed. rand: (use rand_r) ext/mcrypt/mcrypt.c on line 1042 ext/soap/php_http.c on line 467 Fixed. ext/sqlite/libsqlite/src/encode.c on lines 204, 213 (external code library) This code cannot be reached. readdir: (use readdir_r) ext/pcre/pcrelib/pcregrep.c on line 261 This code cannot be reached. main/streams/php_scandir.c on line 74 Fixed. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] thread unsafety inventory
Ilia, Great work. I posted a bug report at www.sqlite.org. Regards, Ron Korving Ilia Alshanetsky [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 27-Nov-06, at 3:24 PM, Ron Korving wrote: gmtime: (use gmtime_r) ext/interbase/ibase_query.c on line 679 Fixed. ext/pdo_sqlite/sqlite/src/date.c on line 948 (external code library) This code cannot be reached since we compile libsqlite with date functions. sapi/thttpd_patch on lines 282, 1355, 2298 External application patch, can't be helped. ctime: (use ctime_r) ext/mime_magic/mime_magic.c on line 1759 Fixed. localtime: (use localtime_r) ext/com_dotnet/com_variant.c on line 818 Win32 only code and there localtime is already thread-safe. ext/pdo_sqlite/sqlite/src/date.c on line 415 (external code library) ext/sqlite/libsqlite/src/date.c on line 419 (external code library) ext/xmlrpc/libxmlrpc/xmlrpc.c on line 234 (external code library) ext/zip/lib/zip_dirent.c on lines 398, 525 (external code library) Fixed. You may want to report the sqlite issues to sqlite devs so that they can apply a fix in their code base as well. sapi/thttpd_patch on line 2300 (external code library) External application patch, can't be helped. crypt: (use crypt_r) ext/standard/crypt.c on line 149 Fixed. rand: (use rand_r) ext/mcrypt/mcrypt.c on line 1042 ext/soap/php_http.c on line 467 Fixed. ext/sqlite/libsqlite/src/encode.c on lines 204, 213 (external code library) This code cannot be reached. readdir: (use readdir_r) ext/pcre/pcrelib/pcregrep.c on line 261 This code cannot be reached. main/streams/php_scandir.c on line 74 Fixed. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Cross-extension resource
Sara,
Sorry if the question was answered before, I will try to look harder next
time.
Just for the record:
- I ended up doing what you suggested but in MINIT. Given the facts you
provided, I'll change it to RINIT.
- The php_mysql.h file doesn't include the constants for the resource name,
so I defined a constant in my own code.
- The php_mysql_conn type is not defined in the .h file, so it was also
replicated.
You're again right about the inclusion of the function in Appendix A, I was
worried if this usage was correct enough.
Again, thank you all very much for your work and specially to you Sara for
sharing your knowledge.
Regards,
Mauro.
-Original Message-
From: Sara Golemon [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 30, 2006 3:42 AM
To: Mauro N. Infantino
Cc: internals@lists.php.net
Subject: [PHP-DEV] Re: Cross-extension resource
Surprising how often this question comes up
/* True global to store local copy of mysql's le_link */
static int local_mysql_le = -1;
PHP_RINIT_FUNCTION(myext)
{
if (local_mysql_le == -1) {
local_mysql_le = zend_fetch_list_dtor_id(mysql link);
}
return SUCCESS;
}
A few notes about this solution:
(1) I'm doing this in RINIT because, prior to PHP 5.1,
there's no way to
enforce load order for shared extensions, so it's possible
that your ext
will load prior to mysql and therefore the list ID won't have been
registered during the time of MINIT. If you know that MySQL
will always
be loaded prior to your extension (either because of local policy or
because you're only targeting 5.1 or later -- which has module
dependencies), then you can do it once in MINIT and be done with it.
(2) The name mysql link is case sensitive and must match
the resource
type name you're looking for precisely. There's also no
guard against
the (unlikely) possibility that some other extension registers a
resource named mysql link which isn't actually a MySQL link.
(3) You should guard against the possibility that no matching list id
will be found for that name (perhaps MySQL isn't loaded), so
be sure to
put some error checking in there... Hint: This function returns 0 on
failure.
(4) You'll probably need to fetch mysql link persistent as well...
I think this function is covered in Appendix A, but the cat
is on my lap
and I can't reach the bookshelf from here
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] make test flag?
I noticed the make test command may need the -n flag added so that it will exclude already installed ini files. Specifically this causes a problem when running make test on a system that already has the same DSO installed so it tries to load it twice (once via the installed ini and again for the test). Perhaps there's other places where this causes problems? ... -n No php.ini file will be used diff --git a/Makefile.global b/Makefile.global index ec86927..237c1a6 100644 --- a/Makefile.global +++ b/Makefile.global @@ -74,7 +74,7 @@ test: all TEST_PHP_EXECUTABLE=$(PHP_EXECUTABLE) \ TEST_PHP_SRCDIR=$(top_srcdir) \ CC=$(CC) \ - $(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo extension=$ $dlname)` tests/; \ + $(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php -n -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo extension=$$dlname)` tests/; \ elif test ! -z $(SAPI_CLI_PATH) test -x $(SAPI_CLI_PATH); then \ TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \ TEST_PHP_SRCDIR=$(top_srcdir) \ -Brian Shire [EMAIL PROTECTED] [EMAIL PROTECTED] aim: int80h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
