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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
