Will PHP ever "grow up" and have threading?
in [General]
|
From: Rene Veerman on 24 Mar 2010 06:34 On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham <tommyhp2(a)gmail.com> wrote: > > Funny you should mention all that. Let's say that you're longer with > that company, either by direct employment or contract consultant. > You've implemented C because you need 'thread'. Now your replacement > comes in and has no clue about C even though your replacement is a PHP > guru. How much headache is maintenance gonna be? Scalability? > Portability? wow.... > Thanks for posting this before i had to. +1, +1, +1...
From: Lester Caine on 24 Mar 2010 06:38 Per Jessen wrote: > Rene Veerman wrote: > >> what you're suggesting is highly intrusive in my work-style, one that >> you're not affected by at all. > > Hmm, you're the one suggesting a change, I'm suggesting no change. How > can "no change" be intrusive? > >> in fact if you make things more difficult for me, i have less time to >> release opensource code of my own. > > Well, we can't have that, so how about we stick to "no change", thereby > not making anything more difficult for you. It will remain exactly as > difficult as it is today. That sounds very good to me! I'm STILL working through the warnings PHP5.3 introduced. It it improve anything. No ..... 5.2 still works just as well! Ican well understand why people stayed with PHP4 for so long - but I never used that myself. Perhaps we need PHPforDummies and PHPforPros ... I'll stick with the Dummies version, if I want the pro version I can go back to C++. ;) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php
From: Stuart Dallas on 24 Mar 2010 06:39 On 24 Mar 2010, at 10:34, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham <tommyhp2(a)gmail.com> wrote: >> >> Funny you should mention all that. Let's say that you're longer with >> that company, either by direct employment or contract consultant. >> You've implemented C because you need 'thread'. Now your replacement >> comes in and has no clue about C even though your replacement is a PHP >> guru. How much headache is maintenance gonna be? Scalability? >> Portability? wow.... >> > Thanks for posting this before i had to. > > +1, +1, +1... You realise, of course, that the same argument applies to using advanced features of PHP, such as threading should it ever be supported. -Stuart -- http://stut.net/
From: Per Jessen on 24 Mar 2010 06:42 Tommy Pham wrote: > On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas <stuttle(a)gmail.com> > wrote: >> Give us a real example of why you think it should be >> supported and I guarantee we can come up with a way to get you what >> you want without requiring massive changes to the core of your chose= n >> tool. And if we can't then you may actually convince us that >> threading would be a valuable feature to have available. >=20 > I did give a real life example, ie e-commerce site mentioned earlier.= How many _concurrent_ users do you expect - which order of magnitude: 10,100,1000,10000? > Amazon has the similar features of my example except they have about > 30 million products without (i18n). Their I18n is different web > server & db & site layout which is completely different from my > example.=20 Understood. > Setting I18n aside, having the same features as my example=20 > with about 30 million products to response in about 3 seconds is very= > good. Even though my example only have about 750,000 products, the > translations for the requested languages makes it into 750,000 * 6 =3D= > 4,500,000 rows of product descriptions. This is e-commerce site not = a > data warehouse/mining. What would happen then if the site has over > 20,000,000 product skus with similar language translations for the > descriptions? 20,000,000 * 6 =3D ... big number to me... Thinking out loud - maybe it would make sense to have a separate database instance/machine per language? That would enable to you to start them all on one machine, but shift to another once the load increases. (not dynamically, but with time). If that's not a feasible option, maybe a mysql cluster or a very large database server? =20 --=20 Per Jessen, Z=C3=BCrich (12.2=C2=B0C)
From: Per Jessen on 24 Mar 2010 06:44
Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <per(a)computer.org> wrote:= >> Tommy Pham wrote: >> >>> What I find funny is that one of opponents of PHP threads earlier >>> mentioned that how silly it would be to be using C in a web app.=20= >>> Now I hear people mentioning C when they need "productivity" or >>> "speed"... >>> >> >> I think I was the one to mention the latter, but as I started out >> saying, and as others have said too, it's about the right tool for >> the right job. =C2=A0When choosing a tool, there are a number of fac= tors >> to consider - developer productivity, available skills, future >> maintenance, performance, scalability, portability, parallelism, >> performance etcetera. >> >=20 > Funny you should mention all that. Let's say that you're longer with= > that company, either by direct employment or contract consultant. > You've implemented C because you need 'thread'. Now your replacement= > comes in and has no clue about C even though your replacement is a PH= P > guru. How much headache is maintenance gonna be? Scalability? > Portability? wow.... Who was the idi... who hired someone who wasn't suited for the job?=20 Tommy, that's a moot argument. You can't fit a square peg in a round hole. =20 --=20 Per Jessen, Z=C3=BCrich (12.5=C2=B0C) |