On Wed, Mar 24, 2010 at 3:49 PM, Tommy Pham <tommy...@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 3:34 PM, Robert Cummings <rob...@interjinn.com> wrote:
>> Tommy Pham wrote:
>>> On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings <rob...@interjinn.com>
>>> wrote:
>>>> Tommy Pham wrote:
>>>>> On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen <p...@computer.org> wrote:
>>>>>> Tommy Pham wrote:
>>>>>>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <p...@computer.org> wrote:
>>>>>>>> Tommy Pham wrote:
>>>>>>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <p...@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?

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to