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

On Wed, Mar 24, 2010 at 3:49 PM, Tommy Pham <tommyhp2@gmail.com> wrote: > On Wed, Mar 24, 2010 at 3:34 PM, Robert Cummings <robert@interjinn.com> wrote: >> Tommy Pham wrote: >>> >>> On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings <robert@interjinn.com> >>> wrote: >>>> >>>> Tommy Pham wrote: >>>>> >>>>> On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen <per@computer.org> wrote: >>>>>> >>>>>> Tommy Pham wrote: >>>>>> >>>>>>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <per@computer.org> >>>>>>> wrote: >>>>>>>> >>>>>>>> Tommy Pham wrote: >>>>>>>> >>>>>>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen >>>>>>>>> <per@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.. >>>>>>>>>>> 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.  When choosing a tool, there are a number >>>>>>>>>> of factors >>>>>>>>>> to consider - developer productivity, available skills, >>>>>>>>>> future >>>>>>>>>> maintenance, performance, scalability, portability, >>>>>>>>>> parallelism, >>>>>>>>>> performance etcetera. >>>>>>>>>> >>>>>>>>> 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.... >>>>>>>> >>>>>>>> Who was the idi... who hired someone who wasn't suited for the >>>>>>>> job? >>>>>>>> Tommy, that's a moot argument.  You can't fit a square >>>>>>>> peg in a round >>>>>>>> hole. >>>>>>>> >>>>>>>> -- >>>>>>>> Per Jessen, Zürich (12.5°C) >>>>>>>> >>>>>>> Suited for the job?  You mean introduce more complexity to a problem >>>>>>> that what could be avoided to begin with if PHP has thread support? >>>>>>> hmmm.... >>>>>> >>>>>> Tommy, it's perfectly simple:  in my company we hire people with C >>>>>> skills for C programming jobs. We hire people with database skills to >>>>>> be database administrators.  We hire people with Linux skills to work >>>>>> on Linux systems.  We explicitly do _not_ hire PHP web-programmers to >>>>>> maintain our C code.  And vice versa for that matter.  No problem, no >>>>>> complexity. >>>>>> >>>>>> >>>>>> -- >>>>>> Per Jessen, Zürich (13.4°C) >>>>>> >>>>>> >>>>> That may just work out fine if you work directly for the company with >>>>> all the proper staffing.  But some of us work as consultants or for >>>>> companies without the proper staffing.  As such, let's dissect what >>>>> you mentioned: >>>>> >>>>> 1) PHP with internal thread support >>>>> 2) PHP with external C/C++ thread support >>>>> >>>>> * Performance - having external thread support, now you have to call >>>>> an extension (more memory usage and CPU cycles).  If you happen to >>>>> have a C/C++ guru who can then code that thread support into PHP >>>>> extension, wouldn't it still perform better at the core vs as an >>>>> extension because it's not talking to a 'middle man'?  Having >>>>> said >>>>> that, not everyone has access to a C/C++ guru.  Thus not mass >>>>> availability. >>>> >>>> Are you suggesting that you need to be a guru in C to write threaded C >>>> code? >>>> I think the word you're looking for is competent. >>>> >>>>> * Portability - if you're currently running PHP on Windows, but manage >>>>> to convince management to switch to *BSD/Linux, then you'd have to >>>>> rewrite that external thread support.  But for us consultants, we may >>>>> have 1 project the runs on Windows, the next may be *BSD/Linux.  PHP >>>>> code snippets goes a lot further versus your custom work around. >>>>> * Managability - should your need to upgrade PHP for either bug fix, >>>>> new features you'd want to implement to add more functionality to your >>>>> site, will that then break your custom external solution?  How much >>>>> more manageable is it if it's done under 1 language versus 2+? >>>> >>>> Are you suggesting cross platform thread libraries don't exist? I wonder >>>> how >>>> Apache does it... or MySQL... or any number of open source cross-platform >>>> systems. If they implement their own, then by the virtue of the source >>>> being >>>> open, you can feel free to incorporate. >>>> >>>> Cheers, >>>> Rob. >>>> -- >>>> http://www.interjinn.com >>>> Application and Templating Framework for PHP >>>> >>> >>> Suppose I have an idea and make it a project.  I'd then want to make >>> it open source and offer it to the world.  With your custom thread >>> solution, how much acceptance is it going to be for a decent PHP >>> programmer to implement versus something that's already in pure PHP. >>> Unzip/rar/tar > minor config for DB > Live.  How does that sound for >>> portability?  Now that you mention cross platform threading, do you >>> think you can take the MySQL compiled for linux and make it work under >>> BSD withouth BSD's linux binaries compatibility, nevermind Windows? >>> Have you looked at the source of PHP? For whatever OS PHP compiles >>> for, it uses the header library pertaining to that OS.  So if I want >>> to implement thread solution similar to Per's solution, I'd have to be >>> an expert at Windows, Linux, and *BSD just to make my PHP open source >>> project to be readily acceptable to the world.  I'll pass on that. >> >> Many open source projects are itches being scratched. More often than not >> you will not be alone in your desire to scratch. When that happens, and if >> you're a good sort of chap or gal, then others will come along and help you >> scratch. Soon, with the right kind of leadership and gameplan, you'll be >> fully embroiled in a scratching orgy with key members scratching the right >> part of the itch. Do you think one person writes all the compatibility stuff >> for any of the above listed systems? No, there's just a lot of scratching >> happening. >> >> Cheers, >> Rob. >> -- >> http://www.interjinn.com >> Application and Templating Framework for PHP >> > > Then the process at which to implement requested features becomes a > crawl because now the project needs to consider the fact how some of > the requested features will it be affected on Windows, Linux, *BSD > versus on just how to realize (PHP coding) those features.  I don't > use Linux nor an expert in it but implementing custom thread solution > like that means understanding about SELinux vs AppArmor vs Grsecurity > or am I wrong?  Look at your project(s) now, if you take your PHP code > and deploy to other platforms that you're currently not using, how > portable is that?  If a particular project happens to depends on > platform/OS specifics, what then? > Also, what happens then when the OS gets a patch for security bug? Is it going to break that non native PHP thread solution?