Re: Will PHP ever "grow up" and have threading?

From: Date: Wed, 24 Mar 2010 19:35:45 +0000
Subject: Re: Will PHP ever "grow up" and have threading?
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.general 
Request: Send a blank email to php-general+get-303350@lists.php.net to get a copy of this message
On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert@interjinn.com> wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings <robert@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. 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.....

« previous php.general (#303350) next »