Le 8 décembre 2009 01:21, Christopher Jones
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
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 defi
Le 8 décembre 2009 01:04, Michael Shadle a écrit :
> 2009/12/7 Jérôme Loyet :
>
> 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.dynami
2009/12/7 Jérôme Loyet :
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.dynami
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:900
2009/12/7 Stanislav Malyshev :
> 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
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
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 he
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,
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 i
2009/12/7 Stanislav Malyshev :
> 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 decisi
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 for
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) o
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 "ste
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 rea
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
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?
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 prefer
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
Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky :
On 2009-12-07, at 10:10 AM, Pierre Joye wrote:
hi,
On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams 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
Sent from my iPhone
On Dec 7, 2009, at 5:57 AM, Jérôme Loyet wrote:
2009/12/7 Reinis Rozitis :
- 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
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
2009/12/7 Ilia Alshanetsky :
>
> On 2009-12-07, at 10:10 AM, Pierre Joye wrote:
>
>> hi,
>>
>> On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams 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, th
On 2009-12-07, at 10:10 AM, Pierre Joye wrote:
> hi,
>
> On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams 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? H
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
hi,
On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams 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
quest
2009/12/7 Ilia Alshanetsky :
> 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 merge
Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky :
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 day
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 al
2009/12/7 Ilia Alshanetsky :
> 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 re
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 th
On 2009-12-07, at 9:42 AM, Pierre Joye wrote:
> 2009/12/7 Ilia Alshanetsky :
>
>> 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 m
2009/12/7 Ilia Alshanetsky :
> 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
2009/12/7 Michael Shadle :
> On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
>> On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal 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 hard
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 bef
On 2009-12-07, at 9:27 AM, Pierre Joye wrote:
> 2009/12/7 Ilia Alshanetsky :
>>
>> 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 for
2009/12/7 Ilia Alshanetsky :
>
> 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
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 st
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 th
2009/12/7 Ilia Alshanetsky :
>
> On 2009-12-07, at 8:54 AM, Pierre Joye wrote:
>
>> Ilia,
>>
>> 2009/12/7 Ilia Alshanetsky :
>>> 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.
>
> Th
On 2009-12-07, at 8:54 AM, Pierre Joye wrote:
> Ilia,
>
> 2009/12/7 Ilia Alshanetsky :
>> 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.
>>
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
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
2009/12/7 Reinis Rozitis :
>> - 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,
Ilia,
2009/12/7 Ilia Alshanetsky :
> 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 i
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 ind
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
2009/12/7 Ilia Alshanetsky :
> 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
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 t
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
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 b
- 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 don
On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
> On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal 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.
>
> Ev
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal 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
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
===
hi!
On Fri, Dec 4, 2009 at 10:18 PM, 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?
I remember some discussions
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
2009/12/7 Antony Dovgal :
> 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
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
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 probl
60 matches
Mail list logo
