Will PHP ever "grow up" and have threading?
in [General]
|
From: Rene Veerman on 24 Mar 2010 15:59 On Wed, Mar 24, 2010 at 9:45 PM, larry(a)garfieldtech.com <larry(a)garfieldtech.com> wrote: > On 3/24/10 2:33 PM, Rene Veerman wrote: > >>> It's a debate. The dev team consider proposals and weigh in on the >>> merits. I >>> was a proponent for goto support during the development of PHP 5. We now >>> have it. If you arguments are valid and there's no technical issue >>> preventing it, and there's someone with time and skill to created the >>> functionality, then it will happen. If not then it won't. I've seen many >>> things added to PHP and I've watched and participated in the threads on >>> internals that have lead to many new features. This is open source, >>> opinions >>> matter, but personal attacks and poor argument do not really make the >>> cut. >>> >> >> hahaha... you dismiss what i believe to be valid explanations without >> any counter-argument besides "more sql hardware!", not just by me but >> by all advocates of threading&shared memory in php. >> >> for some reason, which is still not clear to me, you nay-sayers refuse >> to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") >> evolve to stay useful, relevant even, in a changing market. >> >> and you're blatantly telling me to use a different kind of "hammer", >> one that would force me to rewrite large sections of my existing >> code-base, and one that i have told you i would find for many other >> _valid_ reasons not optimal. > > And what you seem to be missing is that making PHP userspace threaded is > such a major change to the underlying code base and architecture that it > would essentially be a total and complete rewrite, and would require people > to rewrite large portions of their existing PHP userspace code. ehm, my newsscraper does threading via a fopen($threadURLonOwnServer) -> fread(threads,2048)+check for feof($thread) + usleep(50ms) -> if feof($thread) process($threadResults). so with a hack, you can let apache handle the threading, today. i suppose i could write something for shared memory in C++ but doing so would also be a hack that has to be installed on each server, rather than having it neatly as part of php. yet if i can code 'm as addons, it must not be hard to include it in the core. the paradigm "shared nothing" may still be the preferred default if you want, but fact is _current_ PHP can set_time_limit(0) and usleep(50ms) until it has something to do again. so i refute it would require a rewrite of php. both features i request for php6/7 can be put in as addons. > > So it's either you adjust your code to fit the paradigm that PHP is built > for from the ground up, or the entire rest of the world adjusts its code to > fit the paradigm that you think you want to have. that's just not the case imo. > >> basically, you're determining my choice of options without me ever >> having forced you to do something a certain way.. >> >> so you'll have to excuse my strong language. >> it's just letting you know that you shouldn't butt into other peoples >> business when it doesn't really affect you. > > Except having to rewrite all of my code to be thread safe would affect me. > > If you didn't want to have a discussion, which by nature has differing view > points, you shouldn't be on a discussion list. > > --Larry Garfield > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
From: Ashley Sheridan on 24 Mar 2010 15:54 On Wed, 2010-03-24 at 21:50 +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> wrote: > > Rene Veerman wrote: > >> > >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com> > >> wrote: > >>> > >>> Rene Veerman wrote: > >>>> > >>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings <robert(a)interjinn.com> > >>>> wrote: > >>>>> > >>>>> Rene Veerman wrote: > >>>>>> > >>>>>> php is not a hammer, its a programming language. > >>>>> > >>>>> It's hard to discuss anything with someone who doesn't comprehend a > >>>>> metaphor. > >>>> > >>>> haha. "comprehend". you mean "accept". > >>>> that metaphor is stretched to breaking point as far as i'm concerned. > >>>> > >>>>>> one that i feel needs to stay ahead of the computing trend if it is to > >>>>>> be considered a language for large scale applications. > >>>>> > >>>>> Personification of PHP doesn't make your argument any more salient. PHP > >>>>> isn't trying to stay ahead of anything. People are using it to solve > >>>>> problems, not to meet some phantom ideal of a "computing trend" > >>>>> threshold. > >>>>> > >>>>>> but you nay-sayers here have convinced me; i'll be shopping for > >>>>>> another language with which to serve my applications and the weboutput > >>>>>> they produce.. > >>>>>> > >>>>>> thanks for opening my eyes and telling to abandon ship in time. > >>>>> > >>>>> Obviously we didn't open your eyes. > >>>>> > >>>> Well excuse me for not dumping 50-100k lines of my own cms code > >>>> instantly now that i realize that in order to scale it, i could really > >>>> use features like threading and shared memory. > >>> > >>> Actually, you are th eone suggesting dumping your code since you said you > >>> were jumping ship. Many of us suggested that your problems can almost > >>> certainly be mitigated without threading. > >>> > >> > >> "almost certainly". at least you're acknowledging that you might be wrong. > > > > I'm certianly not right all the time. once I thought I was but I was wrong. > > > >> take this example, sorry for the crosspost; > >> > >> my main concern atm is my own cms (50-100k lines of my own); it's > >> graphics-heavy, does fairly complicated db based logic, and if it ever > >> is to be used for a site like facebook, it'll get large dataflows that > >> have to be distributed over the servers used to generate html and > >> accessoiries for end-users. > >> i've built a layer into it that caches the output of oft-used pages > >> (like articles and their comments). > >> but adding many comments / minute to an article would result in quite > >> a bit of overhead, to update the html for that page and distribute it > >> (fast enough) to the relevant servers. > >> > >> i'm worried about php's single-threaded nature; each request has to > >> fetch html updated in the last few seconds, or generate it from a list > >> of comments. that's also a big query from a big table for every > >> end-user.. :( > >> i'd rather keep them comments for an article in shared memory..... > > > > I think you'll find when you get even close to the size of facebook, > > everything you think you know now about how it all stays running will be > > thrown out the window. But then, I'm not a fan of early optimization of this > > magnitude. A good design is usually flexible enough to allow redesign > > without recoding everything. Baby steps to the moon IMHO. > > > yea, well, if i'm going to keep using php i need a path towards > scalability, for this particular problem. > > i'd like to code the kinds of applications with big dataflows. > call me a golddigger all you want, it's what i am ;) > just not in the sexual sense hehe.. > > >Your tools are up to date. Threading is in the future if at all... it's certainly not in the present. > > True, lets _keep_ 'm up-to-date, please. > > And you'd enable other uses of PHP besides helping this > real-time-web-scalability problem. > Why don't you set up a vote to see how many developers actually *want* threading. That would be a good indication of whether or not it is actually worth the PHP development team spending a lot of time on it at the loss of other features which people want more. Thanks, Ash http://www.ashleysheridan.co.uk
From: Rene Veerman on 24 Mar 2010 16:05 On Wed, Mar 24, 2010 at 9:54 PM, Ashley Sheridan <ash(a)ashleysheridan.co.uk>wrote: > On Wed, 2010-03-24 at 21:50 +0200, Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> wrote: > > Rene Veerman wrote: > >> > >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com> > >> wrote: > >>> > >>> Rene Veerman wrote: > >>>> > >>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings <robert(a)interjinn.com> > >>>> wrote: > >>>>> > >>>>> Rene Veerman wrote: > >>>>>> > >>>>>> php is not a hammer, its a programming language. > >>>>> > >>>>> It's hard to discuss anything with someone who doesn't comprehend a > >>>>> metaphor. > >>>> > >>>> haha. "comprehend". you mean "accept". > >>>> that metaphor is stretched to breaking point as far as i'm concerned. > >>>> > >>>>>> one that i feel needs to stay ahead of the computing trend if it is to > >>>>>> be considered a language for large scale applications. > >>>>> > >>>>> Personification of PHP doesn't make your argument any more salient. PHP > >>>>> isn't trying to stay ahead of anything. People are using it to solve > >>>>> problems, not to meet some phantom ideal of a "computing trend" > >>>>> threshold. > >>>>> > >>>>>> but you nay-sayers here have convinced me; i'll be shopping for > >>>>>> another language with which to serve my applications and the weboutput > >>>>>> they produce.. > >>>>>> > >>>>>> thanks for opening my eyes and telling to abandon ship in time. > >>>>> > >>>>> Obviously we didn't open your eyes. > >>>>> > >>>> Well excuse me for not dumping 50-100k lines of my own cms code > >>>> instantly now that i realize that in order to scale it, i could really > >>>> use features like threading and shared memory. > >>> > >>> Actually, you are th eone suggesting dumping your code since you said you > >>> were jumping ship. Many of us suggested that your problems can almost > >>> certainly be mitigated without threading. > >>> > >> > >> "almost certainly". at least you're acknowledging that you might be wrong. > > > > I'm certianly not right all the time. once I thought I was but I was wrong. > > > >> take this example, sorry for the crosspost; > >> > >> my main concern atm is my own cms (50-100k lines of my own); it's > >> graphics-heavy, does fairly complicated db based logic, and if it ever > >> is to be used for a site like facebook, it'll get large dataflows that > >> have to be distributed over the servers used to generate html and > >> accessoiries for end-users. > >> i've built a layer into it that caches the output of oft-used pages > >> (like articles and their comments). > >> but adding many comments / minute to an article would result in quite > >> a bit of overhead, to update the html for that page and distribute it > >> (fast enough) to the relevant servers. > >> > >> i'm worried about php's single-threaded nature; each request has to > >> fetch html updated in the last few seconds, or generate it from a list > >> of comments. that's also a big query from a big table for every > >> end-user.. :( > >> i'd rather keep them comments for an article in shared memory..... > > > > I think you'll find when you get even close to the size of facebook, > > everything you think you know now about how it all stays running will be > > thrown out the window. But then, I'm not a fan of early optimization of this > > magnitude. A good design is usually flexible enough to allow redesign > > without recoding everything. Baby steps to the moon IMHO. > > > yea, well, if i'm going to keep using php i need a path towards > scalability, for this particular problem. > > i'd like to code the kinds of applications with big dataflows. > call me a golddigger all you want, it's what i am ;) > just not in the sexual sense hehe.. > > >Your tools are up to date. Threading is in the future if at all... it's certainly not in the present. > > True, lets _keep_ 'm up-to-date, please. > > And you'd enable other uses of PHP besides helping this > real-time-web-scalability problem. > > > > Why don't you set up a vote to see how many developers actually *want* > threading. That would be a good indication of whether or not it is actually > worth the PHP development team spending a lot of time on it at the loss of > other features which people want more. > we'd probably lose that vote because so many of you other php programmers refuse to see that we do have good uses for it, and you don't. yet. but ultimately it's a matter of the php dev's team time and effort, so when this thread has run it's course i may go to the internals list and raise it -diplomatically- there.
From: Ashley Sheridan on 24 Mar 2010 16:05 On Wed, 2010-03-24 at 22:05 +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:54 PM, Ashley Sheridan > <ash(a)ashleysheridan.co.uk>wrote: > > > On Wed, 2010-03-24 at 21:50 +0200, Rene Veerman wrote: > > > > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> wrote: > > > Rene Veerman wrote: > > >> > > >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com> > > >> wrote: > > >>> > > >>> Rene Veerman wrote: > > >>>> > > >>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings <robert(a)interjinn.com> > > >>>> wrote: > > >>>>> > > >>>>> Rene Veerman wrote: > > >>>>>> > > >>>>>> php is not a hammer, its a programming language. > > >>>>> > > >>>>> It's hard to discuss anything with someone who doesn't comprehend a > > >>>>> metaphor. > > >>>> > > >>>> haha. "comprehend". you mean "accept". > > >>>> that metaphor is stretched to breaking point as far as i'm concerned. > > >>>> > > >>>>>> one that i feel needs to stay ahead of the computing trend if it is to > > >>>>>> be considered a language for large scale applications. > > >>>>> > > >>>>> Personification of PHP doesn't make your argument any more salient. PHP > > >>>>> isn't trying to stay ahead of anything. People are using it to solve > > >>>>> problems, not to meet some phantom ideal of a "computing trend" > > >>>>> threshold. > > >>>>> > > >>>>>> but you nay-sayers here have convinced me; i'll be shopping for > > >>>>>> another language with which to serve my applications and the weboutput > > >>>>>> they produce.. > > >>>>>> > > >>>>>> thanks for opening my eyes and telling to abandon ship in time. > > >>>>> > > >>>>> Obviously we didn't open your eyes. > > >>>>> > > >>>> Well excuse me for not dumping 50-100k lines of my own cms code > > >>>> instantly now that i realize that in order to scale it, i could really > > >>>> use features like threading and shared memory. > > >>> > > >>> Actually, you are th eone suggesting dumping your code since you said you > > >>> were jumping ship. Many of us suggested that your problems can almost > > >>> certainly be mitigated without threading. > > >>> > > >> > > >> "almost certainly". at least you're acknowledging that you might be wrong. > > > > > > I'm certianly not right all the time. once I thought I was but I was wrong. > > > > > >> take this example, sorry for the crosspost; > > >> > > >> my main concern atm is my own cms (50-100k lines of my own); it's > > >> graphics-heavy, does fairly complicated db based logic, and if it ever > > >> is to be used for a site like facebook, it'll get large dataflows that > > >> have to be distributed over the servers used to generate html and > > >> accessoiries for end-users. > > >> i've built a layer into it that caches the output of oft-used pages > > >> (like articles and their comments). > > >> but adding many comments / minute to an article would result in quite > > >> a bit of overhead, to update the html for that page and distribute it > > >> (fast enough) to the relevant servers. > > >> > > >> i'm worried about php's single-threaded nature; each request has to > > >> fetch html updated in the last few seconds, or generate it from a list > > >> of comments. that's also a big query from a big table for every > > >> end-user.. :( > > >> i'd rather keep them comments for an article in shared memory..... > > > > > > I think you'll find when you get even close to the size of facebook, > > > everything you think you know now about how it all stays running will be > > > thrown out the window. But then, I'm not a fan of early optimization of this > > > magnitude. A good design is usually flexible enough to allow redesign > > > without recoding everything. Baby steps to the moon IMHO. > > > > > yea, well, if i'm going to keep using php i need a path towards > > scalability, for this particular problem. > > > > i'd like to code the kinds of applications with big dataflows. > > call me a golddigger all you want, it's what i am ;) > > just not in the sexual sense hehe.. > > > > >Your tools are up to date. Threading is in the future if at all... it's certainly not in the present. > > > > True, lets _keep_ 'm up-to-date, please. > > > > And you'd enable other uses of PHP besides helping this > > real-time-web-scalability problem. > > > > > > > > Why don't you set up a vote to see how many developers actually *want* > > threading. That would be a good indication of whether or not it is actually > > worth the PHP development team spending a lot of time on it at the loss of > > other features which people want more. > > > > we'd probably lose that vote because so many of you other php programmers > refuse to see that we do have good uses for it, and you don't. yet. > > but ultimately it's a matter of the php dev's team time and effort, so when > this thread has run it's course i may go to the internals list and raise it > -diplomatically- there. So you're basically saying that you'd discount anyone who opposes you purely because you think you know best? Nice attitude. Thanks, Ash http://www.ashleysheridan.co.uk
From: Rene Veerman on 24 Mar 2010 16:15
On Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan <ash(a)ashleysheridan.co.uk>wrote: > > > So you're basically saying that you'd discount anyone who opposes you > purely because you think you know best? > > Nice attitude. > I ain't saying that at all, nor did i intend to imply it. In fact it's the anti-threading/shared-mem camp that thinks they know everything best with their instistance that "throw more hardware at it, more sql servers, more programming languages in a single project" will solve all software design / growth problems with enough efficiency. In this case, you still haven't given me any other reason to oppose the evolution of php with the market trend, other than that it would cost php-dev team time that can be spent on other things. you (that camp) haven't even told me what features you want 'm to spend time on instead. |