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

From: Date: Wed, 24 Mar 2010 22:49:40 +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-303388@lists.php.net to get a copy of this message
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?

« previous php.general (#303388) next »