Re: Will PHP ever "grow up" and have threading?
| From: | Tommy Pham | 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?