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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux