Re: [PHP-DEV] FPM is available in a separate SVN branch
On 05.12.2009 00:18, Stanislav Malyshev wrote: Hi! You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Just curious - any plans for win32 support? If you want to work on it - sure, no problem. But you know me, I have neither knowledge nor desire to work on it myself. Also a heavy loaded server on Windows is something out of this world to me. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On 05.12.2009 03:25, Michael Shadle wrote: What if it was just a modification to the FCGI SAPI, and the FPM management features, config file parsing, all that were in a standalone daemon. That allows for a lot of changes and such to be done in the daemon portion without having to align it with PHP releases That's the thing I want to avoid, actually. Moving something out of PHP just because you're afraid of its release cycles means you make it harder to maintain, not easier. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
2009/12/7 Antony Dovgal t...@daylessday.org: On 05.12.2009 00:18, Stanislav Malyshev wrote: Hi! You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Hi tony, I've been working on php-fpm. If I want to submit patches, what is the best way to do it ? ++ jerome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On 07.12.2009 12:30, Jérôme Loyet wrote: You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Hi tony, I've been working on php-fpm. If I want to submit patches, what is the best way to do it ? Send them to internals@ and CC me, this way they won't be lost for sure. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
hi! On Fri, Dec 4, 2009 at 10:18 PM, Stanislav Malyshev s...@zend.com wrote: Hi! You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Just curious - any plans for win32 support? I remember some discussions about it but I did not follow the recent developments. We can take a look at a possible port once it is ready (when Antony is done with the cleanup). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (107 total -- which includes 46 feature requests) ===[*General Issues]== 50189 Open [PATCH] - unicode byte order difference between SPARC and x86 ===[Apache related]=== 47061 Open User not logged under Apache ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On 50130 Open Segfault of libphp6.so ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg 48478 Open Super-globals cannot be accessed with literal keys ===[COM related]== 45836 Open cannot use com ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 49421 Open Make failure with MySQL 6 and PHP 6.0-dev 50101 Open [PATCH] - Avoid name clash between global and local variable 50237 Open [PATCH] - Enable correct behaviour when building PHP6 with Sun's compilers ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[DOM XML related]== 49463 Open setAttributeNS(http://www.w3.org/2000/xmlns/,xmlns,blah;) produces error ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 46688 Open Return values differ from 5.3 and are also inconsistent 46689 Open Downcoded notices suggest unfinished code in file system? 46990 Assigned Passing UTF8 strings to filesystem functions produce wrong filenames 49479 Open move_uploaded_file is dead ===[GD related]=== 34992 Assigned imageconvolution does not respect alpha 43899 Assigned Problem in displaying right to left connected languages (like persian, arabic) ===[HTTP related]= 49273 Open setcookie() segfaults the php process when adding a positive expires value ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[ICONV related] 48538 Open iconv_strlen() does not reject invalid charset on PHP6 ===[mcrypt related]=== 46834 Assigned Range of mcrypt functions fail on PHP 6.0 ===[MySQL related] 44076 Assigned mysql_result returns nothing with blob ===[ODBC related]= 39756 Open [PATCH] Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Assigned openssl_pkey_get_public() fails when given a private key ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 49270 Open configure fails if PHP source folder path contains spaces ===[Performance problem]== 50157 Open [patch] Replace !strlen(...) with !*... 50238 Analyzed [PATCH] - Using #defines to improve the performance of the TSRMG macro ===[PostgreSQL related]=== 48265 Open Source and result of database have different encodings. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash 47756 Open Segfault on HTML Purifier test suite ===[Scripting Engine problem]= 47154 Open Object properties unset after setting. 49945 Open Array in multipart/form-data ===[Session related]== 44860 Open session_encode() fails for php_binary serializer
Re: [PHP-DEV] FPM is available in a separate SVN branch
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal t...@daylessday.org wrote: That's the thing I want to avoid, actually. Moving something out of PHP just because you're afraid of its release cycles means you make it harder to maintain, not easier. Even if it is just the management component of it? Any of the PHP internals will still stay inside of PHP. It will only be the daemon portion that tells the new SAPI how to behave (spawn more under this pool, kill this child, do that?) etc? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle mike...@gmail.com wrote: On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal t...@daylessday.org wrote: That's the thing I want to avoid, actually. Moving something out of PHP just because you're afraid of its release cycles means you make it harder to maintain, not easier. Even if it is just the management component of it? Any of the PHP internals will still stay inside of PHP. It will only be the daemon portion that tells the new SAPI how to behave (spawn more under this pool, kill this child, do that?) etc? Or, perhaps move it into PECL at least? There are still many things TBD in PHP-FPM, one of them was a discussion about possibly changing the model to make it more accommodating for shared hosting providers. Other features grokked from the wishlist/would be logged as feature requests when I had setup the bug tracker: - Adaptive process support (the major thing lacking) - CPU affinity/load balancing - Config file syntax change - Syslog support - Per-pool php.ini file (should be easy) - See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) - Metrics/reporting, possibly like postfix's anvil reports out, or a way to query the SAPI to get an idea of usage At the moment unless these changes are ready for commitment into a PHP beta build they won't get out until the next one, and so on... at least with PECL there is a clear delineation from core. Anyway, as acting manager for the project I really would like to be able to figure out the future - what we should be doing on the side (obviously trying to work on code and submit it when ready) but do we still maintain the documentation, or will it migrate to php.net then? Since the SAPI includes the config file, now all of a sudden that becomes thrown under the PHP core umbrella for documentation, and the existing XML configuration (and desired nginx style configuration) both do not line up with the INI style configuration that PHP users are used to. This might be one of the main reasons why I think having the daemon/management portion be split out. Otherwise, if it is part of core, then core has to have pages with documentation for all of this as well, bug tracking for it, etc. Quite possibly, if split apart, a better management daemon or tool would be developed as well, as the API would be in place to manage the FPM SAPI'ed PHP processes from an external manager. (Heck, do I see control panel integration points? cpanel/plesk/etc. could now define PHP process quotas per user for example?) Just spitballing here. You're ultimately the master of this domain. I also don't want to spam the list. I'm more than happy to pro/con this offline with you. Or have you tell me flat out what I should be changing on the community side of things. Keep your own svn, but keep it in sync with our branch. Once a feature is complete and assumed bug free, then send the patch to us or Use php.net for the bugtracker now, there is no need for an external website anymore either. Documentation will also be hosted on php.net as well ... etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
- See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external libevent on system now. - Adaptive process support (the major thing lacking) Somewhat done with the 'apache-like' spawning mechanism? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Towards 5.3.2
Hi, so, 5.3.1 out just a few weeks but due to the merge-based process and some delays in there the changelog for 5.3 is already quite long and so I'd like to restart the release process there soon. My current plan has one RC this week, one more before Christmas, maybe Tue 22nd, then a Christmas break, a RC early/mid January and release late January. I don't think we could be faster but having some RC before Christmas might get some people to test it on their new PCs they get, people who won't test otherwise, while on the other side I don't expect too much actual work being done during that time. Given the discussions and ongoing refactoring work I would keep the FPM SAPI out of 5.3.2 but aim for integration with 5.3.3. (Tony / Michael) As a process: In general I think the release branch approach is a good one while we had some trouble as there doesn't seem to be any software to really manage release branches, but the wiki evolved to a good enough merge tracker[1] imo. (The second problem with this approach was some personal distraction I had) Any comments? johannes [1] http://wiki.php.net/todo/php531/log -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Johannes, While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. On 2009-12-07, at 8:37 AM, Johannes Schlüter wrote: Hi, so, 5.3.1 out just a few weeks but due to the merge-based process and some delays in there the changelog for 5.3 is already quite long and so I'd like to restart the release process there soon. My current plan has one RC this week, one more before Christmas, maybe Tue 22nd, then a Christmas break, a RC early/mid January and release late January. I don't think we could be faster but having some RC before Christmas might get some people to test it on their new PCs they get, people who won't test otherwise, while on the other side I don't expect too much actual work being done during that time. Given the discussions and ongoing refactoring work I would keep the FPM SAPI out of 5.3.2 but aim for integration with 5.3.3. (Tony / Michael) As a process: In general I think the release branch approach is a good one while we had some trouble as there doesn't seem to be any software to really manage release branches, but the wiki evolved to a good enough merge tracker[1] imo. (The second problem with this approach was some personal distraction I had) Any comments? johannes [1] http://wiki.php.net/todo/php531/log -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote: I have updated the current RFC accordingly: http://wiki.php.net/rfc/autoload_include So there are three approaches listed in the RFC: 1) http://wiki.php.net/rfc/autoload_include#proposal add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly) 2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire add stream support to include/require 3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path fix up stream_resolve_include_path() to support streams. I would like to call for a vote on the above. For 1) and 3) I invite everybody to optionally also submit a proposal for a name. Finally optionally include in your vote if would like to see this feature added to 5.3.2 or if it should wait for the next minor/major version update instead. I would like to raise this point once more. I am a bit surprised that nobody voted, but I got a lot of feedback from people about this proposal offlist when I first brought this to the list. Then again a lot of those people were not core developers. The fact remains however that a large number of frameworks rely on the @fopen() hack and so offering a better solution sooner rather than later seems like a very good idea. Then again, no vote essentially means sticking with the status quo aka stream_resolve_include_path() (which needs some additional love as the RFC states to really serve for what it was originally intended) when PHP6 comes out. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: Johannes, While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. It was actually the exact opposite. We did not miss patches once we were synced. The way we tracked the patches also let us actually define what must go in and what not, avoiding the classical last minute bad patches. The key to success is to do not let go months between a commit and its merge to the release branch, which was a real pain when we began 5.3.1. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 14:41, Ilia Alshanetsky wrote: While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. I remember that when I was RM that the need for code freezes was one of the most painful things to manage. So not having to deal with that seems like a very appealing target for all involved. As for risk of missed patches and confusion. I think Pierre did the best he could to improve the transparency of the process with the wiki page. However we still have plenty of ways to make this even clearer and more obvious to follow. Especially integration into the bug tracker (aka milestone support) would go a long way here. Making sure that every commit has a bug id attached (or if necessary gets a bug ticket created on the fly and the id injected into the commit) could also help. Obviously such infrastructure will not materialize over night, but I would urge everything to not drop the idea entirely. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Pierre, Actually patches were indeed missed, in fact we almost missed a security fix. As far as the wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't. On 2009-12-07, at 8:46 AM, Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: Johannes, While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. It was actually the exact opposite. We did not miss patches once we were synced. The way we tracked the patches also let us actually define what must go in and what not, avoiding the classical last minute bad patches. The key to success is to do not let go months between a commit and its merge to the release branch, which was a real pain when we began 5.3.1. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Ilia, 2009/12/7 Ilia Alshanetsky i...@prohost.org: Pierre, Actually patches were indeed missed, in fact we almost missed a security fix. Which? We did review *all* 5.3 commits before going final. As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. , let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't. We can add a reason for the rejection (new features and non critical patches have been rejected when we were in the RC phase, obviously :) , but that does not mean the system is bad. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
2009/12/7 Reinis Rozitis r...@roze.lv: - See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external libevent on system now. there is no more patch libevent, it's dependent of official libevent. It's all ok. - Adaptive process support (the major thing lacking) Somewhat done with the 'apache-like' spawning mechanism? As far as I know nohting has been done about adaptive process support or 'apache-like' spawning mechanism. It's been present in conf file without being supported. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 14:54, Pierre Joye wrote: As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. I think it was mentioned on this list sufficiently often, but then again it came along fairly ad hoc. However I do agree that the wiki is not the right place for this in the long run. Like I said, I believe the bug tracker is the place for this by adding milestone support. This would also be the natural place to note why a patch is not merged for example. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Opcode EXT_FCALL_BEGIN and EXT_FCALL_END?
Hi, I am wondering what the opcode EXT_FCALL_BEGIN and EXT_FCALL_END is used for? Thanks -- Mathieu Suen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 2009-12-07, at 8:54 AM, Pierre Joye wrote: Ilia, 2009/12/7 Ilia Alshanetsky i...@prohost.org: Pierre, Actually patches were indeed missed, in fact we almost missed a security fix. Which? We did review *all* 5.3 commits before going final. The max # of file uploads was almost missed. As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: On 2009-12-07, at 8:54 AM, Pierre Joye wrote: Ilia, 2009/12/7 Ilia Alshanetsky i...@prohost.org: Pierre, Actually patches were indeed missed, in fact we almost missed a security fix. Which? We did review *all* 5.3 commits before going final. The max # of file uploads was almost missed. It was not, and we did not forget it because of the automatic TODOs in the wiki (it shows all commits in a list with their states, http://wiki.php.net/todo/php531/log) :-). There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. If one does not want to know something, then there is no way for us to make him cluefull. The wiki has been mentioned hundred of times in this list, but yes, one has to actually read the mails to get a clue :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 15:13, Ilia Alshanetsky wrote: As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. Well that only means we need to make sure that developers know about stuff like this. Do we need an (irregular) newsletter to inform people? I mean we have had this problem as well with commit freezes, but there it was actually a bigger problem. If we do stick with the wiki for now .. then all that needs to happen is to inform relevant developers once .. and nothing breaks if they do not know about it at a fixed date .. like with a commit freeze. In other words, the problem might exist, but its solvable and is unrelated to using a branch or not. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 2009-12-07, at 9:19 AM, Pierre Joye wrote: Which? We did review *all* 5.3 commits before going final. The max # of file uploads was almost missed. It was not, and we did not forget it because of the automatic TODOs in the wiki (it shows all commits in a list with their states, http://wiki.php.net/todo/php531/log) :-). BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: On 2009-12-07, at 9:19 AM, Pierre Joye wrote: Which? We did review *all* 5.3 commits before going final. The max # of file uploads was almost missed. It was not, and we did not forget it because of the automatic TODOs in the wiki (it shows all commits in a list with their states, http://wiki.php.net/todo/php531/log) :-). BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. I think you should reconsider the way you see the whole thing. I did remind Johannes as well while reviewing the commits. That's nice that you did it as well as it just shows that the system worked, double safety. Now, about the way we do releases. Everyone agrees that is a mess, no real plan or ability to define a clear roadmap. 5.3.1 has shown that there is a way to solve that problem without influencing the day to day job of the other core developers while making the release process safer (no last minute breakage due to wild commits for example). There is stilll a lot to do to make this process better and friendly but we are on the right track. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 2009-12-07, at 9:27 AM, Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: On 2009-12-07, at 9:19 AM, Pierre Joye wrote: Which? We did review *all* 5.3 commits before going final. The max # of file uploads was almost missed. It was not, and we did not forget it because of the automatic TODOs in the wiki (it shows all commits in a list with their states, http://wiki.php.net/todo/php531/log) :-). BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. I think you should reconsider the way you see the whole thing. I did remind Johannes as well while reviewing the commits. That's nice that you did it as well as it just shows that the system worked, double safety. If anything it shows the system had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of no and ? is rather alarming, especially when there is no indicator as to why. Additionally, would be possible to get some clarity as to who is actually is the RM for the 5.3.X tree, first it was Johannes, then Johannes and Lukas, now you seem to be playing a big role in it. Can I (we) get some clarity around that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On Mon, 2009-12-07 at 09:21 -0500, Ilia Alshanetsky wrote: It was not, and we did not forget it because of the automatic TODOs in the wiki (it shows all commits in a list with their states, http://wiki.php.net/todo/php531/log) :-). BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. Which only the value in the sample php.ini files was, the fix itself was. And no I don't claim it was perfect and I opened this discussion for the purpose to decide on this. I *think* if we all want the release branch is the better process to create a stable release with less risk. But I can live with either approaches. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
2009/12/7 Michael Shadle mike...@gmail.com: On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle mike...@gmail.com wrote: On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal t...@daylessday.org wrote: That's the thing I want to avoid, actually. Moving something out of PHP just because you're afraid of its release cycles means you make it harder to maintain, not easier. Even if it is just the management component of it? Any of the PHP internals will still stay inside of PHP. It will only be the daemon portion that tells the new SAPI how to behave (spawn more under this pool, kill this child, do that?) etc? Before integration of php-fpm in the official php tree I agreed with you about separating daemon stuff out of php tree and include only necessary functions (communication about spawning, chroot, ...) in php-fastcgi (cgi sapi). But as it's been totaly included as an independant sapi, I don't see any benefit to split. The fpm sapi would be only a patch version of the cgi sapi in order to work exclusively with an external software. This is illogical to me. And as tony has worked on this integration it would be a waste of time to change this. I hear you concerns about frequency of releases. Why don't follow patch against official release on the php-fpm website or something like that ? We have some thinking to do to find a solution that pleases everyone. Or, perhaps move it into PECL at least? What PECL can help here ? Is PECL just a compiled packages library for PHP ? There are still many things TBD in PHP-FPM, one of them was a discussion about possibly changing the model to make it more accommodating for shared hosting providers. Other features grokked from the wishlist/would be logged as feature requests when I had setup the bug tracker: - Adaptive process support (the major thing lacking) - CPU affinity/load balancing - Config file syntax change - Syslog support - Per-pool php.ini file (should be easy) - See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) - Metrics/reporting, possibly like postfix's anvil reports out, or a way to query the SAPI to get an idea of usage At the moment unless these changes are ready for commitment into a PHP beta build they won't get out until the next one, and so on... at least with PECL there is a clear delineation from core. Anyway, as acting manager for the project I really would like to be able to figure out the future - what we should be doing on the side (obviously trying to work on code and submit it when ready) but do we still maintain the documentation, or will it migrate to php.net then? Since the SAPI includes the config file, now all of a sudden that becomes thrown under the PHP core umbrella for documentation, and the existing XML configuration (and desired nginx style configuration) both do not line up with the INI style configuration that PHP users are used to. This might be one of the main reasons why I think having the daemon/management portion be split out. Otherwise, if it is part of core, then core has to have pages with documentation for all of this as well, bug tracking for it, etc. Quite possibly, if split apart, a better management daemon or tool would be developed as well, as the API would be in place to manage the FPM SAPI'ed PHP processes from an external manager. (Heck, do I see control panel integration points? cpanel/plesk/etc. could now define PHP process quotas per user for example?) Just spitballing here. You're ultimately the master of this domain. I also don't want to spam the list. I'm more than happy to pro/con this offline with you. Or have you tell me flat out what I should be changing on the community side of things. Keep your own svn, but keep it in sync with our branch. Once a feature is complete and assumed bug free, then send the patch to us or Use php.net for the bugtracker now, there is no need for an external website anymore either. Documentation will also be hosted on php.net as well ... etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: If anything it shows the system had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of no and ? is rather alarming, especially when there is no indicator as to why. Wait, and now developers do not read NEWS either? Oh my... it is worst that I initially thought :) Additionally, would be possible to get some clarity as to who is actually is the RM for the 5.3.X tree, first it was Johannes, then Johannes and Lukas, now you seem to be playing a big role in it. Can I (we) get some clarity around that. Given that I work full time on PHP itself (or closely related projects, and not only for the windows part of them), I give a hand to Johannes to keep 5.3 releases on track, merges, etc. I don't think there is such a need of a clarification or do you consider that having people helping other developers or RM cannot happen without an official statement on the mailing list ? /joking :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 2009-12-07, at 9:42 AM, Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: If anything it shows the system had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of no and ? is rather alarming, especially when there is no indicator as to why. Wait, and now developers do not read NEWS either? Oh my... it is worst that I initially thought :) The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them. As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On Mon, 7 Dec 2009, Ilia Alshanetsky wrote: While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. I second that; I had no clue what was going on, and I only found out about this wiki thing afterwards. Please get things back to normal like we do with 5.2. Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them. As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-). Ok, so what you are arguing about is that you don't know why something was not merged. That's something we like to improve but it has nothing to do with the extra branch, absolutely nothing. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Pierre, It has everything to do with the separate branch. Our current approach, (as flawed as it maybe) ensures patches are not missed, since there is no separate branch, so patches go into the release tree. With the new approach if something is not merged it is not part of the release. This also makes it confusing for the users, since the dev fixing the bug indicates on the bug tracker the issue was resolved, and will be part of the next release. And then the next release comes out and the bug/issue is still there... On 2009-12-07, at 9:55 AM, Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them. As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-). Ok, so what you are arguing about is that you don't know why something was not merged. That's something we like to improve but it has nothing to do with the extra branch, absolutely nothing. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them. As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-). Ok, so what you are arguing about is that you don't know why something was not merged. That's something we like to improve but it has nothing to do with the extra branch, absolutely nothing. Cheers, Pierre, What's the status of the SNMP fixes? I see that SNMP is still not in the 5.3.x code. Larry
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: Pierre, It has everything to do with the separate branch. Our current approach, (as flawed as it maybe) ensures patches are not missed, since there is no separate branch, so patches go into the release tree. With the new approach if something is not merged it is not part of the release. This also makes it confusing for the users, since the dev fixing the bug indicates on the bug tracker the issue was resolved, and will be part of the next release. And then the next release comes out and the bug/issue is still there... Ok, so we are running in circle. We agreed on that: - we need to add a field to explain why a patch was not merged - a real bug tracker - with roadmap - allow to set a bug as part of a given release roadmap, like when a patch is commited to the dev branches, it can be set to 5.3.2 so the RM can appove merge it - be sure that the merge commits are shown in the bug reports as well However, given that: - we did NOT miss any patches in 5.3.1 - the process was open, mails have been sent to the list, etc. - the deadlines were respected, 1st time in 5.3 releases history I do not understand why you keep saying that it was a major mistake to do it this way. I can understand that the chaotic way fits more to your ideas about how things should work however it totally fails to actually get 3rd parties involved more deeply in our developments (be QA or to integrate latest releases to their products, like most unix distros). What I suggest is to do it again the same way for 5.3.2, I will improve the tools to make it more transparent and full fills your requests (except the bug trackes, which is another major issue that we will have to address very soon as well). Then we can have this discussion again. The reason is that both Johannes and I were happy (not 100% but more than 50% :) with it and it allows us to sleep better during the release phases. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
hi, On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams larryjad...@comcast.net wrote: What's the status of the SNMP fixes? I see that SNMP is still not in the 5.3.x code. Don't hijack threads with off topic questions, thanks (and use text email :). I suppose you refer to the netsmnp library, then I return you the question, what's the status of your work and tests? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
As Lukas pointed out, both approaches have flaws, but I think the new merging approach is much cleaner and prevents people from committing during a freeze. Although the wiki might not be the perfect place to do things, I think the general approach is good. Core developers should know what's going on in the wiki, or at least don't complain. Cheers On 2009-12-07, Ilia Alshanetsky i...@prohost.org wrote: Pierre, Actually patches were indeed missed, in fact we almost missed a security fix. As far as the wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't. On 2009-12-07, at 8:46 AM, Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: Johannes, While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. It was actually the exact opposite. We did not miss patches once we were synced. The way we tracked the patches also let us actually define what must go in and what not, avoiding the classical last minute bad patches. The key to success is to do not let go months between a commit and its merge to the release branch, which was a real pain when we began 5.3.1. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 2009-12-07, at 10:10 AM, Pierre Joye wrote: hi, On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams larryjad...@comcast.net wrote: What's the status of the SNMP fixes? I see that SNMP is still not in the 5.3.x code. Don't hijack threads with off topic questions, thanks (and use text email :). Eh? How is his question off topic? As far as fixes this could be what he is referring to Fixed bug #49990 (SNMP3 warning message about security level printed twice). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Ilia Alshanetsky i...@prohost.org: On 2009-12-07, at 10:10 AM, Pierre Joye wrote: hi, On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams larryjad...@comcast.net wrote: What's the status of the SNMP fixes? I see that SNMP is still not in the 5.3.x code. Don't hijack threads with off topic questions, thanks (and use text email :). Eh? How is his question off topic? As far as fixes this could be what he is referring to Because it has nothing to do with PHP releases or ext/snmp directly but the snmp library on Windows for PHP 5.3 and later. We don't use because the latest smnp releases do not work on Windows. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_5_3 GC segfaults
Hi Rasmus,
Let me know how to reproduce them and I'll try to look into them.
Thanks. Dmitry.
Rasmus Lerdorf wrote:
I'm seeing some GC-related segfaults in current PHP_5_3. I haven't had
time to dive into it very far. All I have is a couple of bts and the
request that triggers it, but it is a gallery2 request and there is a
lot of code there. I'll see if I can get it down to something
manageable. The first bt is:
Program received signal SIGSEGV, Segmentation fault.
0x7f4d6b3df8f1 in gc_zval_possible_root (zv=0x232e098) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0 0x7f4d6b3df8f1 in gc_zval_possible_root (zv=0x232e098) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:143
#1 0x7f4d6b3ce11b in zend_hash_destroy (ht=0x2323e78) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_hash.c:526
#2 0x7f4d6b3c14ff in _zval_dtor_func (zvalue=0x232df78) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_variables.c:43
#3 0x7f4d6b3b5ccd in _zval_dtor (zval_ptr=0x232df58) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_variables.h:35
#4 _zval_ptr_dtor (zval_ptr=0x232df58) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:435
#5 0x7f4d6b3ce11b in zend_hash_destroy (ht=0x2323f88) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_hash.c:526
#6 0x7f4d6b3c14ff in _zval_dtor_func (zvalue=0x232df28) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_variables.c:43
#7 0x7f4d6b3b5ccd in _zval_dtor (zval_ptr=0x23561e8) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_variables.h:35
#8 _zval_ptr_dtor (zval_ptr=0x23561e8) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:435
#9 0x7f4d6b3ce11b in zend_hash_destroy (ht=0x2323ce0) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_hash.c:526
#10 0x7f4d6b3e0e69 in zend_object_std_dtor (object=0x2355790) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects.c:45
#11 0x7f4d6b3e0e89 in zend_objects_free_object_storage
(object=0x232e098) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects.c:114
#12 0x7f4d6b3e47c9 in zend_objects_store_del_ref_by_handle_ex
(handle=9, handlers=value optimized out)
at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects_API.c:220
#13 0x7f4d6b3e47e3 in zend_objects_store_del_ref (zobject=0x2342c00)
at /home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects_API.c:172
#14 0x7f4d6b3b5ccd in _zval_dtor (zval_ptr=0x22fe8b8) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_variables.h:35
#15 _zval_ptr_dtor (zval_ptr=0x22fe8b8) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:435
#16 0x7f4d6b3ce11b in zend_hash_destroy (ht=0x2323bb0) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_hash.c:526
#17 0x7f4d6b3e0e69 in zend_object_std_dtor (object=0x22fe990) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects.c:45
#18 0x7f4d6b3e0e89 in zend_objects_free_object_storage
(object=0x232e098) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects.c:114
#19 0x7f4d6b3e42fc in zend_objects_store_free_object_storage
(objects=0x7f4d6bb79f58) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_objects_API.c:92
#20 0x7f4d6b3b82e5 in shutdown_executor () at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_execute_API.c:298
#21 0x7f4d6b3c21d2 in zend_deactivate () at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend.c:890
#22 0x7f4d6b36e182 in php_request_shutdown (dummy=value optimized
out) at /home/rasmus/src/php/php-src/branches/PHP_5_3/main/main.c:1606
And another:
Program received signal SIGSEGV, Segmentation fault.
zval_mark_grey (pz=0x114f458) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:356
356 p = Z_ARRVAL_P(pz)-pListHead;
(gdb) bt
#0 zval_mark_grey (pz=0x114f458) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:356
#1 0x7f7ef6d57e39 in zval_mark_grey (pz=0x114f458) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:367
#2 0x7f7ef6d5846d in gc_mark_roots () at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:417
#3 gc_collect_cycles () at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:628
#4 0x7f7ef6d3b2a5 in zend_deactivate () at
/home/rasmus/src/php/php-src/branches/PHP_5_3/Zend/zend.c:900
#5 0x7f7ef6ce7182 in php_request_shutdown (dummy=value optimized
out) at /home/rasmus/src/php/php-src/branches/PHP_5_3/main/main.c:1606
#6 0x7f7ef6dc4f83 in php_apache_request_dtor (r=0xee3148) at
/home/rasmus/src/php/php-src/branches/PHP_5_3/sapi/apache2handler/sapi_apache2.c:493
(gdb) p pz
$1 = (zval *) 0x114f458
(gdb) p *pz
$2 = {value = {lval = 0, dval = 0, str = {val = 0x0, len = 17070608}, ht
= 0x0,
Re: [PHP-DEV] FPM is available in a separate SVN branch
Sent from my iPhone On Dec 7, 2009, at 5:57 AM, Jérôme Loyet jer...@loyet.net wrote: 2009/12/7 Reinis Rozitis r...@roze.lv: - See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external libevent on system now. there is no more patch libevent, it's dependent of official libevent. It's all ok. Shows how much I know. I haven't used 0.6.x yet because all my build scripts worked flawlessly with the patch. - Adaptive process support (the major thing lacking) Somewhat done with the 'apache-like' spawning mechanism? As far as I know nohting has been done about adaptive process support or 'apache-like' spawning mechanism. It's been present in conf file without being supported. Correct. Biggest lacking feature. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Pierre Joye wrote: 2009/12/7 Ilia Alshanetsky i...@prohost.org: On 2009-12-07, at 10:10 AM, Pierre Joye wrote: hi, On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams larryjad...@comcast.net wrote: What's the status of the SNMP fixes? I see that SNMP is still not in the 5.3.x code. Don't hijack threads with off topic questions, thanks (and use text email :). Eh? How is his question off topic? As far as fixes this could be what he is referring to Because it has nothing to do with PHP releases or ext/snmp directly but the snmp library on Windows for PHP 5.3 and later. We don't use because the latest smnp releases do not work on Windows. Cheers, They do work. However, Pierre and I have to close the loop on a few things related to VC9. I'll re-engage. Pierre is very busy I know. We all are. Regards, Larry Adams aka TheWitness at cacti dot net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Correct. Biggest lacking feature. While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run more processes in given time period than started) - stepping back to how apache operates with its prefork mechanism (iirc there are even people from php-dev community which suggested running apache with start/maxservers identical so there is always constant number of childs (for php processing) to avoid unwanted/unexpected resource consumption? There should be reasons why it was also dropped from the other external process manager lighty/spawn-fcgi and never planned in webservers like nginx .. I would rather want to see one day php (master process) return FCGI_OVERLOADED for the webserver/application to decide what to do next. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Derick Rethans wrote: On Mon, 7 Dec 2009, Ilia Alshanetsky wrote: While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. I second that; I had no clue what was going on, and I only found out about this wiki thing afterwards. Please get things back to normal like we do with 5.2. Aye. No more wikis or branches. The way 5.2 releases have been done has worked just fine 11 times. No need to reinvent the wheel here. Also, 5.3.2 should include the new output buffering code that fixes about 10 open bugs currently in the tracker. Johannes, you seem to ignore emails, so try check the bugs assigned to you. And hopefully you won't disappear again for weeks. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Hi! Couple of other notes here: 1. I understand this SAPI uses its own XML config format. While it is not unheard of for SAPIs to integrate into external servers and thus have diferent config ways, this one is self contained - so I wonder if it would be possible to make it configured by .ini? We have .ini parser, people know what .ini format is, etc. 2. Do we need value name=php_defines if we already have user ini files? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
For #2 it might no longer be needed that might be up for debate. It's nice to be able to override a single option. But 5.3 with it's htaccess/htscanner behavior might work good enough for most things (but PHP_INI_SYSTEM might be still nice to override one offs instead of having to point to a totally separate ini file) unless you say that there is a global ini file with defaults and the per-pool override is just overrides for that. As for #1 we are working on changing the config file syntax and the idea was to make it use nginx style. I don't think it will fit in ini file format as it needs arrays or some sort of n+1 group structure support/nested options. IIRC array support did just get inplemented in 5.3 did it not? That - may- be an option then. Then fpm could actually share php.ini itself. I guess it depends on if the ini support php has will work well with nested groupings. Sent from my iPhone On Dec 7, 2009, at 10:49 AM, Stanislav Malyshev s...@zend.com wrote: Hi! Couple of other notes here: 1. I understand this SAPI uses its own XML config format. While it is not unheard of for SAPIs to integrate into external servers and thus have diferent config ways, this one is self contained - so I wonder if it would be possible to make it configured by .ini? We have .ini parser, people know what .ini format is, etc. 2. Do we need value name=php_defines if we already have user ini files? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
The problem with running a static amount of processes is trying to figure out the right number. Also it is not elastic in any fashion. Shared hosts would love the elasticity as it will allow sites to flex up and down as needed without giving each individual user more processes than they really need A global max amount of processes or memory consumption metric might be useful to throttle the entire daemon from spawning new children. Sent from my iPhone On Dec 7, 2009, at 10:26 AM, Reinis Rozitis r...@roze.lv wrote: Correct. Biggest lacking feature. While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run more processes in given time period than started) - stepping back to how apache operates with its prefork mechanism (iirc there are even people from php-dev community which suggested running apache with start/maxservers identical so there is always constant number of childs (for php processing) to avoid unwanted/unexpected resource consumption? There should be reasons why it was also dropped from the other external process manager lighty/spawn-fcgi and never planned in webservers like nginx .. I would rather want to see one day php (master process) return FCGI_OVERLOADED for the webserver/application to decide what to do next. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Opcode EXT_FCALL_BEGIN and EXT_FCALL_END?
Hi! I am wondering what the opcode EXT_FCALL_BEGIN and EXT_FCALL_END is used for? When php is in extended opcode mode (usually used by debuggers) these opcodes are generated by the compiler before entering and after exiting function calls (so that the debugger could do step into and step over). They are not used in non-debugging context. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Hi! Personally, I like release branch approach better, provided: 1. For the announced release period, each commit into the tree is logged automatically (I understand the wiki does that? if not we may need to do it) 2. RM takes on himself to make a decision (which is recorded - say, in wiki) on each commit. I.e. if one is not merged, there should be a mark saying RM has reviewed it and decided not to merge, not just forgot it. 3. The URL of this log page is included in RC announcements so people could see what's going on. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Hi! Aye. No more wikis or branches. The way 5.2 releases have been done has worked just fine 11 times. No need to reinvent the wheel here. Actually, it didn't work just fine, it was quite painful (each time one wants to fix the bug one needs to see if we are in freeze or not and then not forget to merge it after freeze is over, and RM can't really keep track of the stuff because he doesn't know how many patches people withheld because of the freeze). The fact that we learned to put up with that does not mean it can't be improved. P.S. for your enjoyment: http://despair.com/tradition.html -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
2009/12/7 Stanislav Malyshev s...@zend.com: Hi! Personally, I like release branch approach better, provided: 1. For the announced release period, each commit into the tree is logged automatically (I understand the wiki does that? if not we may need to do it) 2. RM takes on himself to make a decision (which is recorded - say, in wiki) on each commit. I.e. if one is not merged, there should be a mark saying RM has reviewed it and decided not to merge, not just forgot it. 3. The URL of this log page is included in RC announcements so people could see what's going on. +1 (even though I hate wikis) With one tweak: 2a) Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits should be explicitly merged in separate commit. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Hi! With one tweak: 2a) Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits should be explicitly merged in separate commit. Right, I agree (I implied that but it's good to say this explicitly). As for wiki, I don't care if it's wiki, shmiki or anything - only thing important is that we have a list of things which is public so RM has it and anybody can see what happens with it. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
On 07.12.2009, at 20:46, Stanislav Malyshev wrote: Hi! With one tweak: 2a) Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits should be explicitly merged in separate commit. Right, I agree (I implied that but it's good to say this explicitly). As for wiki, I don't care if it's wiki, shmiki or anything - only thing important is that we have a list of things which is public so RM has it and anybody can see what happens with it. I think the wiki can only be a temporary solution and this should be managed entirely inside the bug tracker (*dream*). A new bug tracker that addresses our needs as they are today would really help in so many ways. But its obviously a big task. However for 5.3.2 it would be ideal to at least parse out bug ticket id's from the commit messages and when a reason for not merging a ticket is added to the wiki it would be automatically submitted to the bug tracker as a comment. Not sure how easily this could be done though and I cannot commit time to checking this out myself :-/ regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Hi! As for #1 we are working on changing the config file syntax and the idea was to make it use nginx style. I don't think it will fit in ini file format as it needs arrays or some sort of n+1 group structure support/nested options. Nesting can be done by name, and .ini can do arrays. See here: http://php.net/parse_ini_file and also here: http://framework.zend.com/manual/en/zend.config.adapters.ini.html for how you can do stuff with .ini's :) IIRC array support did just get inplemented in 5.3 did it not? That -may- be an option then. Then fpm could actually share php.ini itself. [] was working in 5.2 too. 5.3 can do indexes. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Hi! I think the wiki can only be a temporary solution and this should be managed entirely inside the bug tracker (*dream*). A new bug tracker that addresses our needs as they are today would really help in so many ways. But its obviously a big task. yes, it will be temporary, but it will be an improvement. If somebody would want to work on Bugtracker NG - all power to him, but in the meantime if we have solution that we can make work for now, and we have people willing to take it - let's do it. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
2009/12/7 Stanislav Malyshev s...@zend.com:
Hi!
As for #1 we are working on changing the config file syntax and the idea
was to make it use nginx style. I don't think it will fit in ini file format
as it needs arrays or some sort of n+1 group structure support/nested
options.
Nesting can be done by name, and .ini can do arrays. See here:
http://php.net/parse_ini_file
and also here:
http://framework.zend.com/manual/en/zend.config.adapters.ini.html
for how you can do stuff with .ini's :)
IIRC array support did just get inplemented in 5.3 did it not? That -may-
be an option then. Then fpm could actually share php.ini itself.
Yes INI is natively handled in PHP (and adding the missing include
function is easy) and I already did it. But the syntax is not that
good for php-fpm, try to configure apache, tomcat or nginx with INI
syntax ... it's a pain in the ass as xml is. Despite all that, php-fpm
aim is to run as a standalone daemon which has never been the aim of
any sapi before (maybe I'm wrong) and therefore INI syntax has never
been used in a such context.
Here is en example of nginx syntax and then INI ... I my mind there is
no comparaison.
pid /var/run/php-fpm.pid;
error_log /var/log/php-fpm.log;
log_level notice;
emergency_restart_threshold 10;
emergency_restart_interval 1m;
process_control_timeout 5s;
daemonize no;
worker {
name default;
listen {
address tcp:127.0.0.1:9000;
backlog -1;
owner nobody;
group nogroup;
mode 0666;
}
php_define short_open_tag=On;
user nobody;
group nogroup;
static {
max_children 5;
}
dynamic {
max_children 20;
StartServers 5;
MinSpareServers 5;
MaxSpareServers 15;
}
request_terminate_timeout 0s;
request_slowlog_timeout 0s;
slowlog /var/log/php-fpm.log.slow;
rlimit_files 1024;
rlimit_core 0;
chroot /usr/local/nginx/html;
chdir /;
catch_workers_output yes;
max_requests 500;
allowed_clients 127.0.0.1;
env HOSTNAME=$HOSTNAME;
env PATH=/usr/local/bin:/usr/bin:/bin;
}
And the same with ini
pid = /var/run/php-fpm.pid
error_log = /var/log/php-fpm.log
log_level = notice
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 5s
daemonize = no
worker.name= default;
worker.listen.address = tcp:127.0.0.1:9000
worker.listen.backlog = -1
worker.listen.owner = nobody
worker.listen.group = nogroup
worker.listen.mode = 0666
worker.php_defineshort_open_tag = On
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynamic.max_spare_servers = 15
worker.request_terminate_timeout = 0s
worker.request_slowlog_timeout = 0s
worker.slowlog = /var/log/php-fpm.log.slow
worker.rlimit_files = 1024
worker.rlimit_core = 0
worker.chroot = /usr/local/nginx/html
worker.chdir = /
worker.catch_workers_output = yes
worker.max_requests = 5000
worker.allowed_clients = 127.0.0.1
worker.env.HOSTNAME = $HOSTNAME
worker.env.PATH = /usr/local/bin:/usr/bin:/bin
[] was working in 5.2 too. 5.3 can do indexes.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Hi! worker.name= default; worker.listen.address = tcp:127.0.0.1:9000 worker.listen.backlog = -1 worker.listen.owner = nobody worker.listen.group = nogroup worker.listen.mode = 0666 worker.php_defineshort_open_tag = On You could also do it as: [WORKER=default] listen.address = tcp:127.0.0.1:9000 ...etc... env[HOSTNAME]=$HOSTNAME ...etc... -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
2009/12/7 Jérôme Loyet jer...@loyet.net:
so you're saying each worker just has a worker.name prefixed
worker.name = pool1
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynamic.max_spare_servers = 15
...etc...
worker.name = pool2
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynamic.max_spare_servers = 15
...etc...
not something like
worker('pool2').user = nobody
worker('pool2').group = nogroup
etc?
i guess i'm fine with it either was as long as it is easy for end
users. also it would be nice to programatically generate it and be
able to include it (would require php.ini to have include support.
mysql does this with the !include directive, IIRC)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Le 8 décembre 2009 01:04, Michael Shadle mike...@gmail.com a écrit :
2009/12/7 Jérôme Loyet jer...@loyet.net:
so you're saying each worker just has a worker.name prefixed
worker.name = pool1
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynamic.max_spare_servers = 15
...etc...
worker.name = pool2
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynamic.max_spare_servers = 15
...etc...
not something like
worker('pool2').user = nobody
worker('pool2').group = nogroup
etc?
Yes it could be this way ... but you do repeat the pattern ('pool2')
for each entry. There is about 30 lines for each workers ... no
imagine having a multiuser environment with 30 customers ... you have
900 times a useless repeated pattern ... gnurf
i guess i'm fine with it either was as long as it is easy for end
users.
I think we all agree here :) cf my previous comment.
also it would be nice to programatically generate it
What do you mean by programatically generate it, in which goal ?
and be
able to include it (would require php.ini to have include support.
mysql does this with the !include directive, IIRC)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Jérôme Loyet wrote:
Yes it could be this way ... but you do repeat the pattern ('pool2')
for each entry. There is about 30 lines for each workers ... no
imagine having a multiuser environment with 30 customers ... you have
900 times a useless repeated pattern ... gnurf
If there are deficiencies in php.ini syntax, then propose an
enhancement and/or work around them in FPM. Having two syntaxes in
use will be more confusing in the long term.
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Le 8 décembre 2009 01:21, Christopher Jones
christopher.jo...@oracle.com a écrit :
Jérôme Loyet wrote:
Yes it could be this way ... but you do repeat the pattern ('pool2')
for each entry. There is about 30 lines for each workers ... no
imagine having a multiuser environment with 30 customers ... you have
900 times a useless repeated pattern ... gnurf
If there are deficiencies in php.ini syntax, then propose an
enhancement and/or work around them in FPM. Having two syntaxes in
use will be more confusing in the long term.
It could be something like:
; general conf
; [/] optional section
pid=/var/run/php-fpm.pid
log_level=notice
;pool1
[/worker]
name=pool1
[/worker/listen]
address=127.0.0.1:9001
[/worker/pm]
style=dynamic
max_children=32
[/worker/env]
HOSTNAME=$HOSTNAME
[/worker/php_define]
short_open_tags = On
;pool2
[/worker]
name=pool2
[/worker/listen]
address=127.0.0.1:9002
...
In this case conf file is very flat. I don't know if identation is
available with INI (hope so). As there is no closing section all
entries have to be ordered correctly (this is not easy for the end
user).
There is a workarround with adding accolades (or similar):
[/worker{]
[/worker/listen{]
[}]
[}]
But in this case we have almost the same syntax as ngninx (with
brackets arround sections and = signs to separate keys and values).
At the begening of the reflexion the choice of nginx has been made
because most of php-fpm users will use nginx or lighthttp (apache as
its well known module) and some developpement have been made for nginx
at the first place.
As the question is which is the best syntax for end users I want to
ask this question Who are the end users of php-fpm and what are their
willing ?.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
