On Wed, Mar 24, 2010 at 3:49 PM, Tommy Pham <tommyhp2@xxxxxxxxx> wrote: > On Wed, Mar 24, 2010 at 3:34 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: >> Tommy Pham wrote: >>> >>> On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings <robert@xxxxxxxxxxxxx> >>> wrote: >>>> >>>> Tommy Pham wrote: >>>>> >>>>> On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen <per@xxxxxxxxxxxx> wrote: >>>>>> >>>>>> Tommy Pham wrote: >>>>>> >>>>>>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <per@xxxxxxxxxxxx> wrote: >>>>>>>> >>>>>>>> Tommy Pham wrote: >>>>>>>> >>>>>>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <per@xxxxxxxxxxxx> >>>>>>>>> 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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
