Will PHP ever "grow up" and have threading?
in [General]
|
From: Peter Lind on 25 Mar 2010 15:28 On 25 March 2010 20:19, Tommy Pham <tommyhp2(a)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 :) -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 </hype>
From: Tommy Pham on 25 Mar 2010 15:59 On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind <peter.e.lind(a)gmail.com> wrote: > On 25 March 2010 20:19, Tommy Pham <tommyhp2(a)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?
From: Peter Lind on 25 Mar 2010 16:10 On 25 March 2010 20:59, Tommy Pham <tommyhp2(a)gmail.com> wrote: > On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind <peter.e.lind(a)gmail.com> wrote: >> On 25 March 2010 20:19, Tommy Pham <tommyhp2(a)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? > That sounds like your webserver spawning new processes dealing with requests ... possibly combined with connection pooling and asynchronous queries and load balancing, etc, etc. So no, I'm not convinced that PHP with threads would actually deliver much faster than a properly built setup that makes good usage of technology you'll have to use anyway. -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 </hype>
From: Per Jessen on 25 Mar 2010 16:50 Tommy Pham wrote: > I'm presenting the argument for threading. Per is presenting the wor= k > around using asynchronous queries via mysqlnd. I did read that link = a > few days ago, "Although the user can send multiple queries at once, > multiple queries cannot be sent over a busy connection. If a query is= > sent while the connection is busy, it waits until the last query is > finished and discards all its results." Which sounds like threads ->= > multiple connections to not run into that problem. You must have read the wrong page. This is NOT about multiple queries,= it's about _asynchronous_ queries.=20 --=20 Per Jessen, Z=C3=BCrich (15.1=C2=B0C)
From: Per Jessen on 25 Mar 2010 16:53
Peter Lind wrote: > 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.=20 Roughly the same here - I don't think threading belongs in PHP, but if someone decides it's a good idea, I won't be arguing against someone volunteering the effort.=20 /Per --=20 Per Jessen, Z=C3=BCrich (15.7=C2=B0C) |