On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind <peter.e.l...@gmail.com> wrote: > On 25 March 2010 20:19, Tommy Pham <tommy...@gmail.com> wrote: >> Aren't all feature requests must be analyzed the same way? Example, >> namespace, how many of us actually uses it now when there is an >> alternative solution- subfolders - that we've been using since who >> knows how long. I don't know if threads was asked a feature prior >> namespace was implemented. >> > > Yes, you're right. But feature requests are not equal: some present a > bigger payoff than others, and some will be more problematic to > implement than others. If a given language can solve the problems it > meets based on it's current structure, should you necessarily > implement new shiny features, that may present problems? > > I'm not against threads in PHP per se ... I just haven't seen a very > convincing reason for them yet, which is why I'm not very positive > about the thing. The DB scenario could be handled without threads and > current libraries could be improved ... and as long as that's cheaper > than implementing threads, then - personally - I'd need to see more > powerful reasons for threads. > > Luckily, I have no say in the development of PHP, so I won't get in > anyone's way should they choose to implement threads :) > >
Here's my analysis, let's say that you have 1000 requests / second on the web server. Each request has multiqueries which take a total of 1 second to complete. In that one second, how many of those 1000 arrive at the same time (that one instant of micro/nano second)? You see how threads come in? If you have threads that are able finish the requests that come in that instant and able to complete them before the next batch of requests in that same second, wouldn't you agree then that you're delivering faster response time to all your users? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
