Will PHP ever "grow up" and have threading?

I've been using PHP for a decade or so (since PHP/FI) and love it. The one
problem that seems to always keep coming back on enterprise level projects
is the lack of threading. This always means we have to write some back-end
code in Ruby or Java or C/C++ and some hacky database layer or DBUS or
something to communicate with PHP.

Will PHP ever have proper threading? It would sure let the language take
the next logical leap to writing applications and daemons. I love the idea
that Rails/Ruby have where you can just load objects in memory once and
keep using them from page to page (this is NOT the same as a $_SESSION,
it's way more flexible and powerful).

But more importantly, in one application I'm working on, we need to connect
to an Asterisk system for the IVR abilities. This means we have Ruby doing
all that fun stuff and PHP doing the web stuff, but we're also duplicating
a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's
calling in, advertisements served, products shown, etc. We could have used
Rails for the web portion, but I want to stay with PHP and I'm sure I don't
have to explain to you PHPers why that is. Without threads, PHP just isn't
even an option or only one user would be able to call in at a time.

The pcntl stuff is not feasible. It's a hack at best. Spawning multiple
scripts is also a recipie for disaster.

When will the PHP core-devs (Zend?) realize that PHP is much more than a
hook to a database. It's much more than web pages.

Is this a case of "it's too hard"? Or is it a case of PHP core developers
just being douche-bags like they are about the whole
"foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let
the developer choose WHICH of the list of parameters they want to set in a
function/method call aside from being stubborn! Especially when there are
many parameters and you can't overload functions like you can in Java or
other typed languages)

As usual, I created a poll here too:
http://www.rapidpoll.net/awp1ocy

Past polls are below:
http://www.rapidpoll.net/8opnt1e
http://www.rapidpoll.net/arc1opy (although someone hacked this poll and
loaded up the 76 votes like a little cheater)


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

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

Perhaps if you asked a question you'd get an answer rather than coming off as
an angry immature crybaby in your last paragraph... No, I'm not going to
dignify your post with a real answer. Come back when you can ask a real
question and maybe you'll get a real answer.

--Larry Garfield

On Monday 22 March 2010 07:02:30 pm Daevid Vincent wrote:
> I've been using PHP for a decade or so (since PHP/FI) and love it. The one
> problem that seems to always keep coming back on enterprise level projects
> is the lack of threading. This always means we have to write some back-end
> code in Ruby or Java or C/C++ and some hacky database layer or DBUS or
> something to communicate with PHP.
>
> Will PHP ever have proper threading? It would sure let the language take
> the next logical leap to writing applications and daemons. I love the idea
> that Rails/Ruby have where you can just load objects in memory once and
> keep using them from page to page (this is NOT the same as a $_SESSION,
> it's way more flexible and powerful).
>
> But more importantly, in one application I'm working on, we need to connect
> to an Asterisk system for the IVR abilities. This means we have Ruby doing
> all that fun stuff and PHP doing the web stuff, but we're also duplicating
> a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's
> calling in, advertisements served, products shown, etc. We could have used
> Rails for the web portion, but I want to stay with PHP and I'm sure I don't
> have to explain to you PHPers why that is. Without threads, PHP just isn't
> even an option or only one user would be able to call in at a time.
>
> The pcntl stuff is not feasible. It's a hack at best. Spawning multiple
> scripts is also a recipie for disaster.
>
> When will the PHP core-devs (Zend?) realize that PHP is much more than a
> hook to a database. It's much more than web pages.
>
> Is this a case of "it's too hard"? Or is it a case of PHP core developers
> just being douche-bags like they are about the whole
> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java or
> other typed languages)
>
> As usual, I created a poll here too:
> http://www.rapidpoll.net/awp1ocy
>
> Past polls are below:
> http://www.rapidpoll.net/8opnt1e
> http://www.rapidpoll.net/arc1opy (although someone hacked this poll and
> loaded up the 76 votes like a little cheater)
>

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

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

That's okay Larry, YOU don't have to answer.

Sorry my post offended you Larry (and anyone else equally offended).

....and yes. I AM angry that they refuse to add functionality to the PHP
language that MANY people have been requesting, just because they are
stubborn. I'll spare you the links to the threads (no pun intended) as you
can easily find them.

Have a lovely day!

Your best friend always,

Daevid.

> -----Original Message-----
> From: Larry Garfield [mailto:larry@garfieldtech.com]
> Sent: Monday, March 22, 2010 5:39 PM
> To: php-general@lists.php.net
> Subject: Re: [PHP] Will PHP ever "grow up" and have threading?
>
> Perhaps if you asked a question you'd get an answer rather
> than coming off as
> an angry immature crybaby in your last paragraph... No, I'm
> not going to
> dignify your post with a real answer. Come back when you can
> ask a real
> question and maybe you'll get a real answer.
>
> --Larry Garfield
>

> > Is this a case of "it's too hard"? Or is it a case of PHP
> core developers
> > just being douche-bags like they are about the whole
> > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO
> reason NOT to let
> > the developer choose WHICH of the list of parameters they
> want to set in a
> > function/method call aside from being stubborn! Especially
> when there are
> > many parameters and you can't overload functions like you
> can in Java or
> > other typed languages)


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

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

On Monday 22 March 2010 20:59:21 Daevid Vincent wrote:
> That's okay Larry, YOU don't have to answer.
>
> Sorry my post offended you Larry (and anyone else equally offended).
>
> ...and yes. I AM angry that they refuse to add functionality to the PHP
> language that MANY people have been requesting, just because they are
> stubborn. I'll spare you the links to the threads (no pun intended) as you
> can easily find them.
>
> Have a lovely day!
>
> Your best friend always,
>
> Daevid.
>
> > -----Original Message-----
> > From: Larry Garfield [mailto:larry@garfieldtech.com]
> > Sent: Monday, March 22, 2010 5:39 PM
> > To: php-general@lists.php.net
> > Subject: Re: [PHP] Will PHP ever "grow up" and have threading?
> >
> > Perhaps if you asked a question you'd get an answer rather
> > than coming off as
> > an angry immature crybaby in your last paragraph... No, I'm
> > not going to
> > dignify your post with a real answer. Come back when you can
> > ask a real
> > question and maybe you'll get a real answer.
> >
> > --Larry Garfield
> >
> > > Is this a case of "it's too hard"? Or is it a case of PHP
> >
> > core developers
> >
> > > just being douche-bags like they are about the whole
> > > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO
> >
> > reason NOT to let
> >
> > > the developer choose WHICH of the list of parameters they
> >
> > want to set in a
> >
> > > function/method call aside from being stubborn! Especially
> >
> > when there are
> >
> > > many parameters and you can't overload functions like you
> >
> > can in Java or
> >
> > > other typed languages)
>

You could implement the features yourself.
--
Blessings
David M.
I have been driven to my knees many times by the overwhelming conviction that
I had nowhere else to go.

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

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

David McGlone wrote:
> On Monday 22 March 2010 20:59:21 Daevid Vincent wrote:
>> That's okay Larry, YOU don't have to answer.
>>
>> Sorry my post offended you Larry (and anyone else equally offended).
>>
>> ...and yes. I AM angry that they refuse to add functionality to the PHP
>> language that MANY people have been requesting, just because they are
>> stubborn. I'll spare you the links to the threads (no pun intended) as you
>> can easily find them.
>>
>> Have a lovely day!
>>
>> Your best friend always,
>>
>> Daevid.
>>
>>> -----Original Message-----
>>> From: Larry Garfield [mailto:larry@garfieldtech.com]
>>> Sent: Monday, March 22, 2010 5:39 PM
>>> To: php-general@lists.php.net
>>> Subject: Re: [PHP] Will PHP ever "grow up" and have threading?
>>>
>>> Perhaps if you asked a question you'd get an answer rather
>>> than coming off as
>>> an angry immature crybaby in your last paragraph... No, I'm
>>> not going to
>>> dignify your post with a real answer. Come back when you can
>>> ask a real
>>> question and maybe you'll get a real answer.
>>>
>>> --Larry Garfield
>>>
>>>> Is this a case of "it's too hard"? Or is it a case of PHP
>>> core developers

Subscribe to internals. Read the archives. The truth is out there.

>>>> just being douche-bags like they are about the whole

That's just rude.

>>>> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO
>>> reason NOT to let
>>>
>>>> the developer choose WHICH of the list of parameters they
>>> want to set in a

There are reasons. You would know this if you had done the legwork
before opening your mouth and letting crap fall out.

>>>> function/method call aside from being stubborn! Especially
>>> when there are
>>>
>>>> many parameters and you can't overload functions like you
>>> can in Java or

PHP is NOT Java.

>>>> other typed languages)

Nor is it OTHER types languages.

> You could implement the features yourself.

Damn, Mr McGlone beat me to it :)

When you set the subject line of your rant to something like "Will PHP
ever 'grow up'", I expect your argument to at least be rationale,
logical, and quite possibly contain a patch. It's called "open source"
because you too can make changes.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

It's code design problem you face, there is loots of solutions to "use
treading" in php. (analyse the way ms C# and VB creates and handles
threads, and when you have done that you can create a couple of php
scripts to acquire the same result).

Read GOF (gang of fore) Design Patterns: Elements of Reusable
Object-Oriented Software (ISBN 0-201-63361-2) and PHP 5 Power
Programming (ISBN 0-131-47149-X)

Start reading and stop being an AHole.

2010/3/23 Daevid Vincent :
> I've been using PHP for a decade or so (since PHP/FI) and love it. The on=
e
> problem that seems to always keep coming back on enterprise level project=
s
> is the lack of threading. This always means we have to write some back-en=
d
> code in Ruby or Java or C/C++ and some hacky database layer or DBUS or
> something to communicate with PHP.
>
> Will PHP ever have proper threading? It would sure let the language take
> the next logical leap to writing applications and daemons. I love the ide=
a
> that Rails/Ruby have where you can just load objects in memory once and
> keep using them from page to page (this is NOT the same as a $_SESSION,
> it's way more flexible and powerful).
>
> But more importantly, in one application I'm working on, we need to conne=
ct
> to an Asterisk system for the IVR abilities. This means we have Ruby doin=
g
> all that fun stuff and PHP doing the web stuff, but we're also duplicatin=
g
> a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's
> calling in, advertisements served, products shown, etc. We could have use=
d
> Rails for the web portion, but I want to stay with PHP and I'm sure I don=
't
> have to explain to you PHPers why that is. Without threads, PHP just isn'=
t
> even an option or only one user would be able to call in at a time.
>
> The pcntl stuff is not feasible. It's a hack at best. Spawning multiple
> scripts is also a recipie for disaster.
>
> When will the PHP core-devs (Zend?) realize that PHP is much more than a
> hook to a database. It's much more than web pages.
>
> Is this a case of "it's too hard"? Or is it a case of PHP core developers
> just being douche-bags like they are about the whole
> "foo($set_this_parameter=3D$bar);" bull$hit??! (there is NO reason NOT to=
let
> the developer choose WHICH of the list of parameters they want to set in =
a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java or
> other typed languages)
>
> As usual, I created a poll here too:
> http://www.rapidpoll.net/awp1ocy
>
> Past polls are below:
> http://www.rapidpoll.net/8opnt1e
> http://www.rapidpoll.net/arc1opy (although someone hacked this poll and
> loaded up the 76 votes like a little cheater)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
MvH / Hans Åhlin
Tel: +46761488019
http//www.kronan-net.com/

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

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

> >>>> Is this a case of "it's too hard"?
>
> Subscribe to internals. Read the archives. The truth is out there.

I have Googled a while on this and don't see much of anything about "PHP
threading" of use. Just a bunch of people desperately wishing for this
feature and trying to hack some way of doing it. Hence my asking here.

>>>> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO
>>> reason NOT to let
>>>
>>>> the developer choose WHICH of the list of parameters they
>>> want to set in a

> There are reasons. You would know this if you had done the legwork
> before opening your mouth and letting crap fall out.

I have researched this. (http://bugs.php.net/bug.php?id=47331) The only
reason I see given for this lack of feature is "it was decided that you can
pass an array parameter instead". This isn't a solution, it's a hack. AND
it only works if you are creating a new function or adding to a function.
It does nothing for existing functions that have many parameters. Why
wouldn't you want to make an already amazing language better and more
flexible. I honestly see zero downside or complication to this. In fact I
am working on a site coded in PHP by Python people, and often find exactly
what I suggest in the code because Python can do this. Ironically it works
by dumb luck b/c PHP ignores the assignment or something and so the
parameters just happened to line up. Even C# can do this.

> >>>> many parameters and you can't overload functions like you
> >>> can in Java or
>
> PHP is NOT Java.
>
> >>>> other typed languages)
>
> Nor is it OTHER types languages.

Uh. Pretty much EVERY other major language has threading. C++, C#, Java,
Ruby, Python and even the archaic Perl.

I KNOW PHP is not Java. That's why I use it. That doesn't take away from
the fact it still needs to have threading to compete as a serious language
if you ever want to do anything more than web pages.

> > You could implement the features yourself.
>
> Damn, Mr McGlone beat me to it :)

That's such a STUPID retort I'm so sick of hearing from the FOSS community.
"build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++
coder -- that's WHY I use PHP. :-\ So, you just stay content with the
status quo. I will continue to ask for features to enhance the language.
They may fall on deaf ears, but sometimes... just sometimes... The squeaky
wheel get's the grease.

> When you set the subject line of your rant to something like
> "Will PHP
> ever 'grow up'", I expect your argument to at least be rationale,
> logical, and quite possibly contain a patch. It's called
> "open source"
> because you too can make changes.

It was logical and rational. I gave examples of why threads are needed in
PHP and why it's STILL considered a sub-language by many enterprise level
people, and also why it will NEVER be used for anything more than web pages
until threading is implemented.

By "grow up", I mean exactly that. PHP needs to be considered a contender
and an equal to other enterprise level languages, not this little amateur
language that script kiddies use. While we here may know the power and
virtues of the language, I assure you that most of the world still views it
as a toy language. And spare me your examples of Google or Twitter or some
other large site that uses it. I'm saying, as a whole, it is still viewed
that way by most enterprises. But more importantly, it is IMPOSSIBLE for
PHP to be used in writing daemons or anything of any complexity save web
pages. This is one reason why Python is used for most of your Linux
scripts. Or why Java/C# are used for applications. And honestly, I'd say a
big reason that Rails has taken off even.

You're all getting hung up on my little paragraph rant about the parameter
feature that is desperately missing from PHP too. I'm sorry I threw that
into the mix, I didn't realize it would confuse you all so much from the
main topic.

Clearly you had nothing of value to add to the question(s) and only wished
to chastise me for using harsh words which offended your delicate ears. I'm
sorry, but when a project like PHP is made for the masses to use, and when
many people are asking for useful, sane and reasonable features, and the
internal devs simply dismiss them because they don't feel like implementing
something (or maybe they don't have the skills to), I call bullshit. And
then to hide under the safety net of "well then submit a patch" is just
cowardice. I suspect that even *if* I submitted the perfect patch, that the
internal devs would not put it in the main tree because THEY are
fundamentally against the idea, so it's a Catch22. You need their blessing
either way. As John Acton said, "Power corrupts; absolute power corrupts
absolutely".



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

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

--00c09f7f9efba3711704826ebde3
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 22, 2010 at 10:23 PM, Daevid Vincent wrote:

> > >>>> Is this a case of "it's too hard"?
> >
> > Subscribe to internals. Read the archives. The truth is out there.
>
> I have Googled a while on this and don't see much of anything about "PHP
> threading" of use. Just a bunch of people desperately wishing for this
> feature and trying to hack some way of doing it. Hence my asking here.
>
> >>>> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO
> >>> reason NOT to let
> >>>
> >>>> the developer choose WHICH of the list of parameters they
> >>> want to set in a
>
> > There are reasons. You would know this if you had done the legwork
> > before opening your mouth and letting crap fall out.
>
> I have researched this. (http://bugs.php.net/bug.php?id=47331) The only
> reason I see given for this lack of feature is "it was decided that you can
> pass an array parameter instead". This isn't a solution, it's a hack. AND
> it only works if you are creating a new function or adding to a function.
> It does nothing for existing functions that have many parameters. Why
> wouldn't you want to make an already amazing language better and more
> flexible. I honestly see zero downside or complication to this. In fact I
> am working on a site coded in PHP by Python people, and often find exactly
> what I suggest in the code because Python can do this. Ironically it works
> by dumb luck b/c PHP ignores the assignment or something and so the
> parameters just happened to line up. Even C# can do this.
>
> > >>>> many parameters and you can't overload functions like you
> > >>> can in Java or
> >
> > PHP is NOT Java.
> >
> > >>>> other typed languages)
> >
> > Nor is it OTHER types languages.
>
> Uh. Pretty much EVERY other major language has threading. C++, C#, Java,
> Ruby, Python and even the archaic Perl.
>
> I KNOW PHP is not Java. That's why I use it. That doesn't take away from
> the fact it still needs to have threading to compete as a serious language
> if you ever want to do anything more than web pages.
>
> > > You could implement the features yourself.
> >
> > Damn, Mr McGlone beat me to it :)
>
> That's such a STUPID retort I'm so sick of hearing from the FOSS community.
> "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++
> coder -- that's WHY I use PHP. :-\ So, you just stay content with the
> status quo. I will continue to ask for features to enhance the language.
> They may fall on deaf ears, but sometimes... just sometimes... The squeaky
> wheel get's the grease.
>
> > When you set the subject line of your rant to something like
> > "Will PHP
> > ever 'grow up'", I expect your argument to at least be rationale,
> > logical, and quite possibly contain a patch. It's called
> > "open source"
> > because you too can make changes.
>
> It was logical and rational. I gave examples of why threads are needed in
> PHP and why it's STILL considered a sub-language by many enterprise level
> people, and also why it will NEVER be used for anything more than web pages
> until threading is implemented.
>
> By "grow up", I mean exactly that. PHP needs to be considered a contender
> and an equal to other enterprise level languages, not this little amateur
> language that script kiddies use. While we here may know the power and
> virtues of the language, I assure you that most of the world still views it
> as a toy language. And spare me your examples of Google or Twitter or some
> other large site that uses it. I'm saying, as a whole, it is still viewed
> that way by most enterprises. But more importantly, it is IMPOSSIBLE for
> PHP to be used in writing daemons or anything of any complexity save web
> pages. This is one reason why Python is used for most of your Linux
> scripts. Or why Java/C# are used for applications. And honestly, I'd say a
> big reason that Rails has taken off even.
>
> You're all getting hung up on my little paragraph rant about the parameter
> feature that is desperately missing from PHP too. I'm sorry I threw that
> into the mix, I didn't realize it would confuse you all so much from the
> main topic.
>
> Clearly you had nothing of value to add to the question(s) and only wished
> to chastise me for using harsh words which offended your delicate ears. I'm
> sorry, but when a project like PHP is made for the masses to use, and when
> many people are asking for useful, sane and reasonable features, and the
> internal devs simply dismiss them because they don't feel like implementing
> something (or maybe they don't have the skills to), I call bullshit. And
> then to hide under the safety net of "well then submit a patch" is just
> cowardice. I suspect that even *if* I submitted the perfect patch, that the
> internal devs would not put it in the main tree because THEY are
> fundamentally against the idea, so it's a Catch22. You need their blessing
> either way. As John Acton said, "Power corrupts; absolute power corrupts
> absolutely".
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi Deavid,

At this point, I find that when I need threading capabilities, I switch over
to developing with C# or Java most of the time, but it would be nice to stay
in PHP for these tasks (I, too, looked into the pcntl technique and that
just didn't seem like the right way to handle them.)

Yes, your last paragraph was a doozy, and few will accuse you of long-term
political aspirations in any arena ;) However, I will go on record saying
that having threading would be a feature I'd very much appreciate, and I
believe it would strengthen the value proposition of PHP in the
ever-changing world of development.

Adam

--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com

--00c09f7f9efba3711704826ebde3--

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

On Mon, Mar 22, 2010 at 7:40 PM, Adam Richardson wro=
te:
> On Mon, Mar 22, 2010 at 10:23 PM, Daevid Vincent wrot=
e:
>
>> > >>>> Is this a case of "it's too hard"?
>> >
>> > Subscribe to internals. Read the archives. The truth is out there.
>>
>> I have Googled a while on this and don't see much of anything about "PHP
>> threading" of use. Just a bunch of people desperately wishing for this
>> feature and trying to hack some way of doing it. Hence my asking here.
>>
>> >>>> "foo($set_this_parameter=3D$bar);" bull$hit??! (there is NO
>> >>> reason NOT to let
>> >>>
>> >>>> the developer choose WHICH of the list of parameters they
>> >>> want to set in a
>>
>> > There are reasons. You would know this if you had done the legwork
>> > before opening your mouth and letting crap fall out.
>>
>> I have researched this. (http://bugs.php.net/bug.php?id=3D47331) The onl=
y
>> reason I see given for this lack of feature is "it was decided that you =
can
>> pass an array parameter instead". This isn't a solution, it's a hack. AN=
D
>> it only works if you are creating a new function or adding to a function=
..
>> It does nothing for existing functions that have many parameters. Why
>> wouldn't you want to make an already amazing language better and more
>> flexible. I honestly see zero downside or complication to this. In fact =
I
>> am working on a site coded in PHP by Python people, and often find exact=
ly
>> what I suggest in the code because Python can do this. Ironically it wor=
ks
>> by dumb luck b/c PHP ignores the assignment or something and so the
>> parameters just happened to line up. Even C# can do this.
>>
>> > >>>> many parameters and you can't overload functions like you
>> > >>> can in Java or
>> >
>> > PHP is NOT Java.
>> >
>> > >>>> other typed languages)
>> >
>> > Nor is it OTHER types languages.
>>
>> Uh. Pretty much EVERY other major language has threading. C++, C#, Java,
>> Ruby, Python and even the archaic Perl.
>>
>> I KNOW PHP is not Java. That's why I use it. That doesn't take away from
>> the fact it still needs to have threading to compete as a serious langua=
ge
>> if you ever want to do anything more than web pages.
>>
>> > > You could implement the features yourself.
>> >
>> > Damn, Mr McGlone beat me to it :)
>>
>> That's such a STUPID retort I'm so sick of hearing from the FOSS communi=
ty.
>> "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/=
C++
>> coder -- that's WHY I use PHP. :-\ So, you just stay content with the
>> status quo. I will continue to ask for features to enhance the language.
>> They may fall on deaf ears, but sometimes... just sometimes... The squea=
ky
>> wheel get's the grease.
>>
>> > When you set the subject line of your rant to something like
>> > "Will PHP
>> > ever 'grow up'", I expect your argument to at least be rationale,
>> > logical, and quite possibly contain a patch. It's called
>> > "open source"
>> > because you too can make changes.
>>
>> It was logical and rational. I gave examples of why threads are needed i=
n
>> PHP and why it's STILL considered a sub-language by many enterprise leve=
l
>> people, and also why it will NEVER be used for anything more than web pa=
ges
>> until threading is implemented.
>>
>> By "grow up", I mean exactly that. PHP needs to be considered a contende=
r
>> and an equal to other enterprise level languages, not this little amateu=
r
>> language that script kiddies use. While we here may know the power and
>> virtues of the language, I assure you that most of the world still views=
it
>> as a toy language. And spare me your examples of Google or Twitter or so=
me
>> other large site that uses it. I'm saying, as a whole, it is still viewe=
d
>> that way by most enterprises. But more importantly, it is IMPOSSIBLE for
>> PHP to be used in writing daemons or anything of any complexity save web
>> pages. This is one reason why Python is used for most of your Linux
>> scripts. Or why Java/C# are used for applications. And honestly, I'd say=
a
>> big reason that Rails has taken off even.
>>
>> You're all getting hung up on my little paragraph rant about the paramet=
er
>> feature that is desperately missing from PHP too. I'm sorry I threw that
>> into the mix, I didn't realize it would confuse you all so much from the
>> main topic.
>>
>> Clearly you had nothing of value to add to the question(s) and only wish=
ed
>> to chastise me for using harsh words which offended your delicate ears. =
I'm
>> sorry, but when a project like PHP is made for the masses to use, and wh=
en
>> many people are asking for useful, sane and reasonable features, and the
>> internal devs simply dismiss them because they don't feel like implement=
ing
>> something (or maybe they don't have the skills to), I call bullshit. And
>> then to hide under the safety net of "well then submit a patch" is just
>> cowardice. I suspect that even *if* I submitted the perfect patch, that =
the
>> internal devs would not put it in the main tree because THEY are
>> fundamentally against the idea, so it's a Catch22. You need their blessi=
ng
>> either way. As John Acton said, "Power corrupts; absolute power corrupts
>> absolutely".
>>
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Hi Deavid,
>
> At this point, I find that when I need threading capabilities, I switch o=
ver
> to developing with C# or Java most of the time, but it would be nice to s=
tay
> in PHP for these tasks (I, too, looked into the pcntl technique and that
> just didn't seem like the right way to handle them.)
>
> Yes, your last paragraph was a doozy, and few will accuse you of long-ter=
m
> political aspirations in any arena ;)  However, I will go on record =
saying
> that having threading would be a feature I'd very much appreciate, and I
> believe it would strengthen the value proposition of PHP in the
> ever-changing world of development.
>
> Adam
>
> --
> Nephtali:  PHP web framework that functions beautifully
> http://nephtaliproject.com
>

Threading is one of the 2 two main reasons why I moved to Java &
asp.net (C#). I've built a PHP based web crawler about 10 years ago.
I ran into some problems: cookies, form handling and submission,
threading, and application variables. I later found some solutions
for cookies, form handling & submission. But no solution for
threading and application variables. Thus the move. Here's a simple
example of one of the many uses for threading. For an e-commerce
site, when the shopper requests for a category (ID), you can have a
thread to get all subcategories for that category, another thread to
get any assigned products, another thread to fetch all manufacturers
listed under that category, another thread to fetch any filters (price
ranges, features, specs, etc) set by the store owner that would fall
under that category, etc... versus what PHP currently doing now:
fetch subcategories, then fetch assigned products, then fetch
manufacturers, etc.... Performance would increase ten fold because of
parallel (threading) operations versus serial operations. Add that to
application variable (less memory usage and CPU cycles due to
creating/GC of variables that could be used for an entire application
regardless of requests & sessions), you have an excellent tool.

Regards,
Tommy

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

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

There can be, and there are, differences between the languages. There
are so many languages out there, and it works like a market place. If
you like the language, use it. It it fails to do what you want, you
switch to another one. There is no need to beg the php developers to
implement anything, as long as you can switch to another language. Teus.

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

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

On Monday 22 March 2010 10:51:14 pm Tommy Pham wrote:
> Threading is one of the 2 two main reasons why I moved to Java &
> asp.net (C#). I've built a PHP based web crawler about 10 years ago.
> I ran into some problems: cookies, form handling and submission,
> threading, and application variables. I later found some solutions
> for cookies, form handling & submission. But no solution for
> threading and application variables. Thus the move. Here's a simple
> example of one of the many uses for threading. For an e-commerce
> site, when the shopper requests for a category (ID), you can have a
> thread to get all subcategories for that category, another thread to
> get any assigned products, another thread to fetch all manufacturers
> listed under that category, another thread to fetch any filters (price
> ranges, features, specs, etc) set by the store owner that would fall
> under that category, etc... versus what PHP currently doing now:
> fetch subcategories, then fetch assigned products, then fetch
> manufacturers, etc.... Performance would increase ten fold because of
> parallel (threading) operations versus serial operations. Add that to
> application variable (less memory usage and CPU cycles due to
> creating/GC of variables that could be used for an entire application
> regardless of requests & sessions), you have an excellent tool.
>
> Regards,
> Tommy

Threading is also much more difficult to program for safely, because thread
order is non-deterministic. Do you really want to unleash hoards of
marginally competent programmers on a threaded enviornment? :-)

Also, the architecture you describe above is fine if you're scaling a single
server really big. PHP is designed to scale the other direction: Just add
more servers. There's no data shared from one request to another, so there's
no need to share data between web heads. Throw a load balancer in front of it
and spin up as many web servers as you need.

The "shared nothing" design is very deliberate. It has design trade-offs like
anything else.

PHP is a web-centric language. It's not really intended for building tier-1
daemon processes, just like you'd be an idiot to try and code your entire web
app in C from the start.

--Larry Garfield

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

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

Op 3/23/10 12:02 AM, Daevid Vincent schreef:
> I've been using PHP for a decade or so (since PHP/FI) and love it. The one



well they certainly ripped you a new one didn't they :)

why no threads? shared-nothing architecture, that's very deliberate, it has draw
backs as well as advantages, either way you have to understand the reasoning and
how to leverage it. shared-nothing obviously doesn't lend itself to writing fast
daemonized code, then again it wasn't meant to.

I'd say that named function/method parameters would be a nice addition though -
although having said that a decent IDE with code completion (DocBlocks) and well commented,
well structured code mitigate the issue, for me anyway.

>
>


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

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

ExecSum:
* +1 for better threading features in PHP.
* overloading = inheritance?
* listreaders plz allow ppl to vent some frustration without
starting a flamewar.

Threading can be implemented in PHP with an
fopen('http://yourserver.com/url')->fread()_all_threads+usle ep(50ms)->fclose()+process
loop.

My own newsscraper threads well like this.
The central script figures out what sites to scrape, and the treaded
subsystem makes sure 1 page per site per N seconds is retrieved.

But i've yet to find a way to keep global objects in memory between
http requests, outside $_SESSION, which i believe is just stored to-
and loaded from disk between http requests.

However, now that i think of it, you could have large pieces of
software stay in memory in a single php script that runs forever and
reads commands (as arrays) out of files (on memory disk?) (put there
by "thread-scripts") and [the "forever running script"] outputs to
stdout, which is caught by the thread-scripts, then passed back to the
thread-caller via fread().
I usually use json for such constructs.
But it's a total hack of course, and i have no idea about performance
issues or even timing bugs. it's "theoretically possible"..

>there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java

well you could shove all the params in an array, then shove that to
the function called, _or_ a preparatory function that calls the old
function.

as for overloading functions, i think with a bit of cleverness you can
come up with a class / set of functions that simulate overloading of
functions and even inheritance. i for a fact simulate polymorphism
with $functionName_fromPluginX ($params).
i smell all the ingredients that would allow you to overload functions
in php aswell. you'd just have to call things a bit differently,
perhaps like
$var = $overloadingManager->call ('functionName',
'context(object-instance-id)', $param1, $param2).

Better yet; aren't OOP's (and php5's) inheritance features (for
classes) similar to functions overloading? k, it forces you to group
such functions into an object, and derivations into subobjects, but
that's not a show-stopper at all.. You can always ignore the object
boundary and have 1 object-tree for all functions that require
overloading.


& lastly, about the politics of this mail-thread;
imo, it's the ones who "open the counterattack" who start the
flamewar, out of something that is clearly in this case just venting
some frustration with at least partially valid reasons..

imo, it would be wiser to have offered the guy some actual tips and/or
a casual "hey, you could've phrased it friendlier, given the fact that
php costs nothing and all, dude", rather than grabbing the
flamethrower and setting it to vaporize.

On Tue, Mar 23, 2010 at 1:02 AM, Daevid Vincent wrote:
> I've been using PHP for a decade or so (since PHP/FI) and love it. The one
> problem that seems to always keep coming back on enterprise level projects
> is the lack of threading. This always means we have to write some back-end
> code in Ruby or Java or C/C++ and some hacky database layer or DBUS or
> something to communicate with PHP.
>
> Will PHP ever have proper threading? It would sure let the language take
> the next logical leap to writing applications and daemons. I love the idea
> that Rails/Ruby have where you can just load objects in memory once and
> keep using them from page to page (this is NOT the same as a $_SESSION,
> it's way more flexible and powerful).
>
> But more importantly, in one application I'm working on, we need to connect
> to an Asterisk system for the IVR abilities. This means we have Ruby doing
> all that fun stuff and PHP doing the web stuff, but we're also duplicating
> a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's
> calling in, advertisements served, products shown, etc. We could have used
> Rails for the web portion, but I want to stay with PHP and I'm sure I don't
> have to explain to you PHPers why that is. Without threads, PHP just isn't
> even an option or only one user would be able to call in at a time.
>
> The pcntl stuff is not feasible. It's a hack at best. Spawning multiple
> scripts is also a recipie for disaster.
>
> When will the PHP core-devs (Zend?) realize that PHP is much more than a
> hook to a database. It's much more than web pages.
>
> Is this a case of "it's too hard"? Or is it a case of PHP core developers
> just being douche-bags like they are about the whole
> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java or
> other typed languages)
>
> As usual, I created a poll here too:
> http://www.rapidpoll.net/awp1ocy
>
> Past polls are below:
> http://www.rapidpoll.net/8opnt1e
> http://www.rapidpoll.net/arc1opy (although someone hacked this poll and
> loaded up the 76 votes like a little cheater)
>

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

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

On Mon, Mar 22, 2010 at 10:01 PM, Larry Garfield w=
rote:
> On Monday 22 March 2010 10:51:14 pm Tommy Pham wrote:
>> Threading is one of the 2 two main reasons why I moved to Java &
>> asp.net (C#).  I've built a PHP based web crawler about 10 years ag=
o.
>> I ran into some problems: cookies, form handling and submission,
>> threading, and application variables.  I later found some solutions
>> for cookies, form handling & submission.  But no solution for
>> threading and application variables.  Thus the move.  Here's a=
simple
>> example of one of the many uses for threading.  For an e-commerce
>> site,  when the shopper requests for a category (ID), you can have =
a
>> thread to get all subcategories for that category, another thread to
>> get any assigned products,  another thread to fetch all manufacture=
rs
>> listed under that category, another thread to fetch any filters (price
>> ranges, features, specs, etc) set by the store owner that would fall
>> under that category, etc...  versus what PHP currently doing now:
>> fetch subcategories, then fetch assigned products, then fetch
>> manufacturers, etc....  Performance would increase ten fold because=
of
>> parallel (threading) operations versus serial operations.  Add that=
to
>> application variable (less memory usage and CPU cycles due to
>> creating/GC of variables that could be used for an entire application
>> regardless of requests & sessions), you have an excellent tool.
>>
>> Regards,
>> Tommy
>
> Threading is also much more difficult to program for safely, because thre=
ad
> order is non-deterministic.  Do you really want to unleash hoards of
> marginally competent programmers on a threaded enviornment? :-)

Marginally competent? I think some, if not many, on this list will
disagree with that ;)

>
> Also, the architecture you describe above is fine if you're scaling a sin=
gle
> server really big.  PHP is designed to scale the other direction: Ju=
st add
> more servers.  There's no data shared from one request to another, s=
o there's
> no need to share data between web heads.  Throw a load balancer in f=
ront of it
> and spin up as many web servers as you need.

Load balancer is used when the server is overloaded with requests and
upgrade has reached it's limit. That's not the same thing as a simple
request where multiple answers are needed as in my example. If you're
thinking of implementing something like my example across multiple
servers (where each server will fetch an answer for a simple request)
via another method, then you're going to face similar issues as
threading ie session/request sync which is equivalent to thread
safety/sync/deadlock but now it's worse because it's spread across
network where performance issues comes in because internal system IO >
(network IO + internal system IO).

>
> The "shared nothing" design is very deliberate.  It has design trade=
-offs like
> anything else.
>
> PHP is a web-centric language.  It's not really intended for buildin=
g tier-1
> daemon processes, just like you'd be an idiot to try and code your entire=
web
> app in C from the start.

Of course since C was engineered to create OSes and (text based) apps
when SMP/MC is unheard of. But we're now in the digital era where
SMP/MC is very common place. In fact, trying to buy a new
desktop/laptop now without a multicore becomes very difficult and
undesired. Why not make use of the SMP/MC? :) PHP seems strive and
somewhat 'imitate' languages like java & asp.net. Not trying to go
off topice but for example: namespace (namespace in asp.net and
packages in java). For many of us that don't use namespace now or
even when it's not yet implemented, we (PHP web app dev) already
implement our own version of it - subfolders. So why not copy or
imitate the features that would be more beneficial if not more
usability ie threading? PHP is already ahead of java & asp.net in
terms of generics, not strong typed.

Regards,
Tommy

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

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

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

Here's another analogy. For those of us in the field long enough, we
see the power of AJAX and we use it in one form or another. For the
newbies, they have yet to see it's power nor the requirements to
implement it. Threading is similar to that. It's not for everybody.
But for those of us that are ready and have need for it, we can
implement it IF IT'S THERE, which is the point of OP, although the way
he put it isn't exactly welcoming... perhaps he had a very long week
and it's just starting too.

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

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

Daevid Vincent wrote:

> I've been using PHP for a decade or so (since PHP/FI) and love it. Th=
e
> one problem that seems to always keep coming back on enterprise level=

> projects is the lack of threading. This always means we have to write=

> some back-end code in Ruby or Java or C/C++ and some hacky database
> layer or DBUS or something to communicate with PHP.

Use the right tool for the right job - PHP is a scripting/interpreted
language, it does not need threading (IMO of course).


--=20
Per Jessen, Zürich (9.4°C)


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

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

Maybe that's what you are looking for : http://nanoserv.si.kz/

Not done with threads, but who cares ?

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

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

hmm i use scripted languages because i prefer and they allow/force
simple-to-read-code.

but that does not mean a scripted language can't evolve to expose
"complicated" code constructs like multi-threading and daemon-building
in a simple manner too.

i'd prefer it if a language like PHP can be used for other things
besides webserving too.
i also think at least some web-apps could benefit from multi-threading
and daemon-building.. particularly web-apps that deal with real-time
dataflows.

and btw, the distinction between compiled and scripted is not a hard
one anymore eh.. not with zend and that facebook php-compiler out
there.

On Tue, Mar 23, 2010 at 10:04 AM, Per Jessen wrote:
> Daevid Vincent wrote:
>
>> I've been using PHP for a decade or so (since PHP/FI) and love it. The
>> one problem that seems to always keep coming back on enterprise level
>> projects is the lack of threading. This always means we have to write
>> some back-end code in Ruby or Java or C/C++ and some hacky database
>> layer or DBUS or something to communicate with PHP.
>
> Use the right tool for the right job - PHP is a scripting/interpreted
> language, it does not need threading (IMO of course).
>
>
> --
> Per Jessen, Zürich (9.4°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

> > > You could implement the features yourself.
> >
> > Damn, Mr McGlone beat me to it :)
>
> That's such a STUPID retort I'm so sick of hearing from the FOSS community.
> "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++
> coder -- that's WHY I use PHP. :-\ So, you just stay content with the
> status quo. I will continue to ask for features to enhance the language.
> They may fall on deaf ears, but sometimes... just sometimes... The squeaky
> wheel get's the grease.

I didn't intend for my reply to sound nasty. After reading your OP, I see that
you are a very experienced programmer and I meant for it as a suggestion.

--
Blessings
David M.
I have been driven to my knees many times by the overwhelming conviction that
I had nowhere else to go.

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

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

On 23 March 2010 00:02, Daevid Vincent wrote:
> douche-bags

I think this is about the best way to get the wrong attention.

Not everyone has a sense of humour like yours.

Maybe no one has a sense of humour like yours.

Good luck.

Richard.

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

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

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

Rene Veerman wrote:

>
> But i've yet to find a way to keep global objects in memory between
> http requests, outside $_SESSION, which i believe is just stored to-
> and loaded from disk between http requests.

You can store sessions in a cache and avoid the disk IO.

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

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

On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote:
>
> Use the right tool for the right job - PHP is a scripting/interpreted
> language, it does not need threading (IMO of course).
>
>
> --
> Per Jessen, Zürich (9.4°C)
>
>

I couldn't agree more. But here's a real life example. Your client
has a forum and is using phpbb for their in house use. They also have
an in house custom PHP app, integrated with phpbb, built to suit their
needs. Now they want to implement some kind of CMS. You come in and
implemented a PHP based CMS to integrate into their existing
applications. Then you realize something troublesome, you have a
performance issue where it could be resolved by implementing thread.
What are you going to do? Are you going to say to the client "We seem
to have a problem. I suggest we migrate to Java or ASP.Net because
threading will resolve the performance issue." Or are you going to
spend who knows how long to try find a hack to resolve the issue?
What do you think the client's response is when their need for the
solution requires a short time frame of, if not immediate,
implementation?

Regards,
Tommy

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

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

Tommy Pham wrote:

> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote:=

>>
>> Use the right tool for the right job - PHP is a scripting/interprete=
d
>> language, it does not need threading (IMO of course).
>>
>>
>> --
>> Per Jessen, Zürich (9.4°C)
>>
>>
>=20
> I couldn't agree more. But here's a real life example. Your client
> has a forum and is using phpbb for their in house use. They also hav=
e
> an in house custom PHP app, integrated with phpbb, built to suit thei=
r
> needs. Now they want to implement some kind of CMS. You come in and=

> implemented a PHP based CMS to integrate into their existing
> applications. Then you realize something troublesome, you have a
> performance issue where it could be resolved by implementing thread.
> What are you going to do?=20

The standard, mature, experienced answer is - buy a bigger box.=20

[snip]
> What do you think the client's response is when their need for the
> solution requires a short time frame of, if not immediate,
> implementation?

There are no immediate solutions to immediate performance problems. If=

you have a poor design that restricts your throughput, you can 1) throw=

hardware at it or 2) change the design. At some point you'll hit yet
another limit with 1), and you are forced back to 2). Somewhere along
the line the original designer has presumably left or been made to.=20


/Per

--=20
Per Jessen, Zürich (7.5°C)


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

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

On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen wrote:
> Tommy Pham wrote:
>
>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote:
>>>
>>> Use the right tool for the right job - PHP is a scripting/interpreted
>>> language, it does not need threading (IMO of course).
>>>
>>>
>>> --
>>> Per Jessen, Zürich (9.4°C)
>>>
>>>
>>
>> I couldn't agree more.  But here's a real life example.  Your =
client
>> has a forum and is using phpbb for their in house use.  They also h=
ave
>> an in house custom PHP app, integrated with phpbb, built to suit their
>> needs.  Now they want to implement some kind of CMS.  You come=
in and
>> implemented a PHP based CMS to integrate into their existing
>> applications.  Then you realize something troublesome, you have a
>> performance issue where it could be resolved by implementing thread.
>> What are you going to do?
>
> The standard, mature, experienced answer is - buy a bigger box.
>

The company started small. As their business grows because they have
products & services that do not exist in the marketplace, their
hardware are already growing along side with it, (load balancers,
clusters). So then your solution is buy bigger/more boxes? What if
the their server room is filled and already using recent hardware.
Their current business needs doesn't need to move to a bigger
building. What then? Hire data center's services? What if they want
to protect their proprietary break through products and services?
What about unnecessary additional total cost of ownership (licenses,
power consumption, etc...) for more/bigger boxes, even if they have
available space, that could be avoided by just implementing threads?

> [snip]
>> What do you think the client's response is when their need for the
>> solution requires a short time frame of, if not immediate,
>> implementation?
>
> There are no immediate solutions to immediate performance problems. =C2=
=A0If
> you have a poor design that restricts your throughput, you can 1) throw
> hardware at it or 2) change the design.  At some point you'll hit ye=
t
> another limit with 1), and you are forced back to 2).  Somewhere alo=
ng
> the line the original designer has presumably left or been made to.
>
>
> /Per
>
> --
> Per Jessen, Zürich (7.5°C)
>

If throwing hardware at it won't work because of the above mentioned,
then you would change the design right? How long would that take?
What if PHP has threads, how long would it take you implement threads
with minor changes versus and overhaul of application design, coding,
QA, etc... In summary, you're saying that PHP can not grow/evolve with
business right? If the company started small and want to use
available open source solutions, then grow quickly because of their
unique and quality products and services, and become enterprise level
with-in a few years, what then? Slow down business growth just so
that IT can migrate everything to another language? Of all the
enterprise applications I've seen, they used threads.

Regards,
Tommy

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

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

On 3/23/10 6:04 PM, Tommy Pham wrote:

> If throwing hardware at it won't work because of the above mentioned,
> then you would change the design right? How long would that take?
> What if PHP has threads, how long would it take you implement threads
> with minor changes versus and overhaul of application design, coding,
> QA, etc... In summary, you're saying that PHP can not grow/evolve with
> business right? If the company started small and want to use
> available open source solutions, then grow quickly because of their
> unique and quality products and services, and become enterprise level
> with-in a few years, what then? Slow down business growth just so
> that IT can migrate everything to another language? Of all the
> enterprise applications I've seen, they used threads.
>
> Regards,
> Tommy

The word "enterprise" is meaningless in this context because it provides
no context for the distinction. What does "enterprise" mean? Gets
Captain Kirk to his next date? Is OpenOffice.org's plugin download site
enterprise? Is Sony BMG enterprise? The sites for the cities of London
and Athens? Whitehouse.gov?

That's just a couple of sites now running on Drupal, a particular
single-threaded PHP application. That's not counting the thousands of
similar organizations running PHP (not even PHP-wrapping-custom-C like
Yahoo) applications of various and sundry kinds. (Wikipedia anyone?)
PHP *is* in the enterprise and quite happy there.

"Not ready for the enterprise" is a totally meaningless statement.
Similarly, if you cannot think of any way to scale an application that
doesn't involve threads then I question your competence as a programmer.
Sure, threads can be one way to speed things up. There are lots and
lots of others that may be more or less appropriate depending on the
circumstances. Threads have their own scaling issues, namely they have
to live within the same process on the same box. That means when you
hit the maximum size of your server, you're done. That doesn't mean
threads are bad, but they have their trade-offs just like everything
else does.

But let's consider what adding threads to PHP would take. That would
mean making PHP a shared-memory architecture, so that different requests
now operated in the same memory space. That means RAM-based
persistence. That means needing to write thread-safe PHP libraries.
(Not the ones in C; I mean the millions of lines of code of PHP already
out there.)

In short, adding threading support to PHP means PHP is no longer PHP.
It's Java with dollarsigns. It's a complete and total rewrite of the
entire language runtime and environment, and all of the code build atop it.

The idea that you could "just add threads" to PHP and make it
"enterprise-ready" is so naive it's mind boggling.

--Larry Garfield

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

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

2010/3/24 Tommy Pham :
> On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen wrote:
>> Tommy Pham wrote:
>>
>>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote:
>>>>
>>>> Use the right tool for the right job - PHP is a scripting/interpreted
>>>> language, it does not need threading (IMO of course).
>>>>
>>>>
>>>> --
>>>> Per Jessen, Zürich (9.4°C)
>>>>
>>>>
>>>
>>> I couldn't agree more.  But here's a real life example.  Your=
client
>>> has a forum and is using phpbb for their in house use.  They also =
have
>>> an in house custom PHP app, integrated with phpbb, built to suit their
>>> needs.  Now they want to implement some kind of CMS.  You com=
e in and
>>> implemented a PHP based CMS to integrate into their existing
>>> applications.  Then you realize something troublesome, you have a
>>> performance issue where it could be resolved by implementing thread.
>>> What are you going to do?
>>
>> The standard, mature, experienced answer is - buy a bigger box.
>>
>
> The company started small.  As their business grows because they hav=
e
> products & services that do not exist in the marketplace, their
> hardware are already growing along side with it, (load balancers,
> clusters).  So then your solution is buy bigger/more boxes?  Wh=
at if
> the their server room is filled and already using recent hardware.
> Their current business needs doesn't need to move to a bigger
> building.  What then? Hire data center's services?  What if the=
y want
> to protect their proprietary break through products and services?
> What about unnecessary additional total cost of ownership (licenses,
> power consumption, etc...) for more/bigger boxes, even if they have
> available space, that could be avoided by just implementing threads?
>

That screams poor code design. Then to solve the problem might not be
threading or change of language but a reanalyze of the code and the
design, probably a re-write.

>> [snip]
>>> What do you think the client's response is when their need for the
>>> solution requires a short time frame of, if not immediate,
>>> implementation?
>>
>> There are no immediate solutions to immediate performance problems. =C2=
=A0If
>> you have a poor design that restricts your throughput, you can 1) throw
>> hardware at it or 2) change the design.  At some point you'll hit y=
et
>> another limit with 1), and you are forced back to 2).  Somewhere al=
ong
>> the line the original designer has presumably left or been made to.
>>
>>
>> /Per
>>
>> --
>> Per Jessen, Zürich (7.5°C)
>>
>
> If throwing hardware at it won't work because of the above mentioned,
> then you would change the design right?  How long would that take?
> What if PHP has threads, how long would it take you implement threads
> with minor changes versus and overhaul of application design, coding,
> QA, etc... In summary, you're saying that PHP can not grow/evolve with
> business right?  If the company started small and want to use
> available open source solutions, then grow quickly because of their
> unique and quality products and services, and become enterprise level
> with-in a few years, what then?  Slow down business growth just so
> that IT can migrate everything to another language? Of all the
> enterprise applications I've seen, they used threads.
>

Same answer as above.

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



--=20
MvH / Hans Åhlin
Tel: +46761488019
http//www.kronan-net.com/

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

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

Tommy Pham wrote:
> On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen wrote:
>> Tommy Pham wrote:
>>
>>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote:
>>>> Use the right tool for the right job - PHP is a scripting/interpreted
>>>> language, it does not need threading (IMO of course).
>>>>
>>>>
>>>> --
>>>> Per Jessen, Zürich (9.4°C)
>>>>
>>>>
>>> I couldn't agree more. But here's a real life example. Your client
>>> has a forum and is using phpbb for their in house use. They also have
>>> an in house custom PHP app, integrated with phpbb, built to suit their
>>> needs. Now they want to implement some kind of CMS. You come in and
>>> implemented a PHP based CMS to integrate into their existing
>>> applications. Then you realize something troublesome, you have a
>>> performance issue where it could be resolved by implementing thread.
>>> What are you going to do?
>> The standard, mature, experienced answer is - buy a bigger box.
>>
>
> The company started small. As their business grows because they have
> products & services that do not exist in the marketplace, their
> hardware are already growing along side with it, (load balancers,
> clusters). So then your solution is buy bigger/more boxes? What if
> the their server room is filled and already using recent hardware.
> Their current business needs doesn't need to move to a bigger
> building. What then? Hire data center's services?

Very few companies have a legitimate reason to run their own server room
at this point in time and should be using a data center if they are not
already.

Data centers have excellent bandwidth, diesel generators to keep things
live during sustained power outages, temperature control to keep things
cool, and often have technicians on hand with spare parts that can take
care of many hardware issues 24/7.

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

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

Let's go back to my 1st e-commerce example. The manufacturers list is
about 3,700. The categories is about about 2,400. The products list
is right now at 500,000 and expected to be around 750,000. The site
is only in English. The store owner wants to expand and be I18n:
Chinese, French, German, Korean, Spanish. You see how big and complex
that database gets? The store owners want to have this happens when a
customer clicks on a category:

* show all subcategories for that category, if any
* show all products for that category, if any,
* show all manufacturers, used as filtering, for that category and subcategories
* show price range filter for that category
* show features & specifications filter for that category
* show 10 top sellers for that category and related subcategories
* the shopper can then select/deselect any of those filters and
ability to sort by manufacturers, prices, user rating, popularity
(purchased quantity)
* have the ability to switch to another language translation on the fly
* from the moment the shopper click on a link, the response time (when
web browser saids "Done" in the status bar) is 5 seconds or less.
Preferably 2-3 seconds. Will be using stopwatch for the timer.

Now show me a website that meets those requirements and uses PHP, I'll
be glad to support your argument about PHP w/o threads :) BTW, this
is not even enterprise requirement. I may have another possible
project where # products is over 10 million easily. With similar
requirements when the user click on category. Do you think this site,
which currently isn't, can run on PHP?

Regards,
Tommy

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

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

On Tue, Mar 23, 2010 at 6:17 PM, Tommy Pham wrote:
> Let's go back to my 1st e-commerce example.  The manufacturers list =
is
> about 3,700.  The categories is about about 2,400.  The product=
s list
> is right now at 500,000 and expected to be around 750,000.  The site
> is only in English.  The store owner wants to expand and be I18n:
> Chinese, French, German, Korean, Spanish.  You see how big and compl=
ex
> that database gets?  The store owners want to have this happens when=
a
> customer clicks on a category:
>
> * show all subcategories for that category, if any
> * show all products for that category, if any,
> * show all manufacturers, used as filtering, for that category and subcat=
egories
> * show price range filter for that category
> * show features & specifications filter for that category
> * show 10 top sellers for that category and related subcategories

forgot to mention:
* show 10 random sale specials for that category and subcategories

> * the shopper can then select/deselect any of those filters and
> ability to sort by manufacturers, prices, user rating, popularity
> (purchased quantity)
> * have the ability to switch to another language translation on the fly
> * from the moment the shopper click on a link, the response time (when
> web browser saids "Done" in the status bar) is 5 seconds or less.
> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>
> Now show me a website that meets those requirements and uses PHP, I'll
> be glad to support your argument about PHP w/o threads :)  BTW, this
> is not even enterprise requirement.  I may have another possible
> project where # products is over 10 million easily.  With similar
> requirements when the user click on category.  Do you think this sit=
e,
> which currently isn't, can run on PHP?
>
> Regards,
> Tommy
>

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

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

Tommy Pham wrote:
> Let's go back to my 1st e-commerce example. The manufacturers list is
> about 3,700. The categories is about about 2,400. The products list
> is right now at 500,000 and expected to be around 750,000. The site
> is only in English. The store owner wants to expand and be I18n:
> Chinese, French, German, Korean, Spanish. You see how big and complex
> that database gets? The store owners want to have this happens when a
> customer clicks on a category:
>
> * show all subcategories for that category, if any
> * show all products for that category, if any,
> * show all manufacturers, used as filtering, for that category and subcategories
> * show price range filter for that category
> * show features & specifications filter for that category
> * show 10 top sellers for that category and related subcategories
> * the shopper can then select/deselect any of those filters and
> ability to sort by manufacturers, prices, user rating, popularity
> (purchased quantity)
> * have the ability to switch to another language translation on the fly
> * from the moment the shopper click on a link, the response time (when
> web browser saids "Done" in the status bar) is 5 seconds or less.
> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>
> Now show me a website that meets those requirements and uses PHP, I'll
> be glad to support your argument about PHP w/o threads :) BTW, this

I don't currently know a site, sounds like a fun job though.

> is not even enterprise requirement. I may have another possible
> project where # products is over 10 million easily. With similar
> requirements when the user click on category. Do you think this site,
> which currently isn't, can run on PHP?

Yes, I do. There's nothing in your requirements above that sound
particularly difficult for PHP to handle with a good design and lots of
caching... and of course the right hardware. I think you're hung up on
the numbers a bit... those aren't very big numbers for a database.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

On Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote:

> Let's go back to my 1st e-commerce example. The manufacturers list is
> about 3,700. The categories is about about 2,400. The products list
> is right now at 500,000 and expected to be around 750,000. The site
> is only in English. The store owner wants to expand and be I18n:
> Chinese, French, German, Korean, Spanish. You see how big and complex
> that database gets? The store owners want to have this happens when a
> customer clicks on a category:
>
> * show all subcategories for that category, if any
> * show all products for that category, if any,
> * show all manufacturers, used as filtering, for that category and
> subcategories
> * show price range filter for that category
> * show features & specifications filter for that category
> * show 10 top sellers for that category and related subcategories
> * the shopper can then select/deselect any of those filters and
> ability to sort by manufacturers, prices, user rating, popularity
> (purchased quantity)
> * have the ability to switch to another language translation on the fly
> * from the moment the shopper click on a link, the response time (when
> web browser saids "Done" in the status bar) is 5 seconds or less.
> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>
> Now show me a website that meets those requirements and uses PHP, I'll
> be glad to support your argument about PHP w/o threads :) BTW, this
> is not even enterprise requirement. I may have another possible
> project where # products is over 10 million easily. With similar
> requirements when the user click on category. Do you think this site,
> which currently isn't, can run on PHP?

That strikes me as a pretty stiff target, no matter how you look at it.
You effectively want 6 major queries at once, plus response in under 3
seconds on a 750000 row product table. I'm not sure I could produce that
kind of performance in C at the command line. (I'm sure some smart guy
on the list will say he can do it in 2 seconds flat over a 10 Base 2
network with teletypes and acoustic modems.)

Which brings me to my question. Why do people expect console-level
performance from a web browser? It's kind of rhetorical, since people
want everything they can get and more all the time. But if performance
came up as a customer question for me, I'd make it clear that they're
not going to get console-level performance from a web browser, unless
they want to spend a whole lot more money. Neither the world wide web
nor browser software were ever designed primarily with speed in mind.
The internet is not your local 64-bit 10 gigabyte memory loaded machine.

Paul

--
Paul M. Foster

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

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

On Tue, Mar 23, 2010 at 6:57 PM, Paul M Foster wr=
ote:
> On Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote:
>
>> Let's go back to my 1st e-commerce example.  The manufacturers list=
is
>> about 3,700.  The categories is about about 2,400.  The produc=
ts list
>> is right now at 500,000 and expected to be around 750,000.  The sit=
e
>> is only in English.  The store owner wants to expand and be I18n:
>> Chinese, French, German, Korean, Spanish.  You see how big and comp=
lex
>> that database gets?  The store owners want to have this happens whe=
n a
>> customer clicks on a category:
>>
>> * show all subcategories for that category, if any
>> * show all products for that category, if any,
>> * show all manufacturers, used as filtering, for that category and
>> subcategories
>> * show price range filter for that category
>> * show features & specifications filter for that category
>> * show 10 top sellers for that category and related subcategories
>> * the shopper can then select/deselect any of those filters and
>> ability to sort by manufacturers, prices, user rating, popularity
>> (purchased quantity)
>> * have the ability to switch to another language translation on the fly
>> * from the moment the shopper click on a link, the response time (when
>> web browser saids "Done" in the status bar) is 5 seconds or less.
>> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>>
>> Now show me a website that meets those requirements and uses PHP, I'll
>> be glad to support your argument about PHP w/o threads :)  BTW, thi=
s
>> is not even enterprise requirement.  I may have another possible
>> project where # products is over 10 million easily.  With similar
>> requirements when the user click on category.  Do you think this si=
te,
>> which currently isn't, can run on PHP?
>
> That strikes me as a pretty stiff target, no matter how you look at it.
> You effectively want 6 major queries at once, plus response in under 3
> seconds on a 750000 row product table. I'm not sure I could produce that
> kind of performance in C at the command line. (I'm sure some smart guy
> on the list will say he can do it in 2 seconds flat over a 10 Base 2
> network with teletypes and acoustic modems.)
>
> Which brings me to my question. Why do people expect console-level
> performance from a web browser? It's kind of rhetorical, since people
> want everything they can get and more all the time. But if performance
> came up as a customer question for me, I'd make it clear that they're
> not going to get console-level performance from a web browser, unless
> they want to spend a whole lot more money. Neither the world wide web
> nor browser software were ever designed primarily with speed in mind.
> The internet is not your local 64-bit 10 gigabyte memory loaded machine.
>
> Paul
>
> --
> Paul M. Foster
>

The response time, max 5 seconds, will be tested on local gigabit LAN
to ensure the adequate response (optimized DB & code & proper
hardware) without worrying about users' connection limit and site's
upload bandwidth limit (which can easily rectify). Then thereafter
will be doing stress test of about 10 concurrent users. As for the
major queries, that's where threads come in, IMO, because those
queries depend on 1 primary parameter (category ID) and 1 secondary
parameter (language ID). This particular site starts with 500
products about 15 categories, without many of those mentioned filters,
later grew to its current state.

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

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

Paul M Foster wrote:
> On Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote:
>
>> Let's go back to my 1st e-commerce example. The manufacturers list is
>> about 3,700. The categories is about about 2,400. The products list
>> is right now at 500,000 and expected to be around 750,000. The site
>> is only in English. The store owner wants to expand and be I18n:
>> Chinese, French, German, Korean, Spanish. You see how big and complex
>> that database gets? The store owners want to have this happens when a
>> customer clicks on a category:
>>
>> * show all subcategories for that category, if any
>> * show all products for that category, if any,
>> * show all manufacturers, used as filtering, for that category and
>> subcategories
>> * show price range filter for that category
>> * show features & specifications filter for that category
>> * show 10 top sellers for that category and related subcategories
>> * the shopper can then select/deselect any of those filters and
>> ability to sort by manufacturers, prices, user rating, popularity
>> (purchased quantity)
>> * have the ability to switch to another language translation on the fly
>> * from the moment the shopper click on a link, the response time (when
>> web browser saids "Done" in the status bar) is 5 seconds or less.
>> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>>
>> Now show me a website that meets those requirements and uses PHP, I'll
>> be glad to support your argument about PHP w/o threads :) BTW, this
>> is not even enterprise requirement. I may have another possible
>> project where # products is over 10 million easily. With similar
>> requirements when the user click on category. Do you think this site,
>> which currently isn't, can run on PHP?
>
> That strikes me as a pretty stiff target, no matter how you look at it.
> You effectively want 6 major queries at once, plus response in under 3
> seconds on a 750000 row product table. I'm not sure I could produce that
> kind of performance in C at the command line. (I'm sure some smart guy
> on the list will say he can do it in 2 seconds flat over a 10 Base 2
> network with teletypes and acoustic modems.)

I'm not sure why you consider this 6 major queries. To show all
sub-categories for a category is a major query only if you need to
recursively gather sub-categories. Admittedly that would be a slow hit
to the database server on first request, but afterwards one would expect
the tree to be cached so the next request would be very fast due to
priming of the cache.

Show all products for a category should be quite fast, the category
would be associated with an integer ID upon which I would presume
indexing has occured. Presumably "show all" means show all products in a
paged manner. The same principles should show true for manufacturer.

Price range also plays nicely with indexes. Features and specifications
may be a biut of a hump, but it depends. It's hard to say exactly what
is meant by this filter.

The top 10 sellers might be an issue, but I don't see why a cron job
can't handle updating top sellers information so that this is an
indexable field.

I'm not sure why language translation would be an issue. Presumably if
you have support for one, switching to another requires the same legwork
with different pants.

Also, it's notable that all of the search data is based on need to read
only. This screams replication to me if the server is very busy.

The big thing about indexes is that the more rows you add, the time to
retrieve a particular indexed row only grows logarithmically.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

--00163646bd9a2aefb3048283de7b
Content-Type: text/plain; charset=ISO-8859-1

First of all, I'll apologize for the top-post. My DROID doesn't give me the
option of top or bottom. So not ready for enterprise.

Secondly, I'll append to the statements made by Larry that, unless it's
non-web based, there are far more layers involved before, during, and after
PHP's execution. Threading is fantastic.... if you're not relying on several
other components (which are likely non-threaded themselves).

On Mar 23, 2010 7:27 PM, "larry@garfieldtech.com"
wrote:

On 3/23/10 6:04 PM, Tommy Pham wrote:

> If throwing hardware at it won't work because of the above ...
The word "enterprise" is meaningless in this context because it provides no
context for the distinction. What does "enterprise" mean? Gets Captain
Kirk to his next date? Is OpenOffice.org's plugin download site enterprise?
Is Sony BMG enterprise? The sites for the cities of London and Athens?
Whitehouse.gov?

That's just a couple of sites now running on Drupal, a particular
single-threaded PHP application. That's not counting the thousands of
similar organizations running PHP (not even PHP-wrapping-custom-C like
Yahoo) applications of various and sundry kinds. (Wikipedia anyone?) PHP
*is* in the enterprise and quite happy there.

"Not ready for the enterprise" is a totally meaningless statement.
Similarly, if you cannot think of any way to scale an application that
doesn't involve threads then I question your competence as a programmer.
Sure, threads can be one way to speed things up. There are lots and lots
of others that may be more or less appropriate depending on the
circumstances. Threads have their own scaling issues, namely they have to
live within the same process on the same box. That means when you hit the
maximum size of your server, you're done. That doesn't mean threads are
bad, but they have their trade-offs just like everything else does.

But let's consider what adding threads to PHP would take. That would mean
making PHP a shared-memory architecture, so that different requests now
operated in the same memory space. That means RAM-based persistence. That
means needing to write thread-safe PHP libraries. (Not the ones in C; I mean
the millions of lines of code of PHP already out there.)

In short, adding threading support to PHP means PHP is no longer PHP. It's
Java with dollarsigns. It's a complete and total rewrite of the entire
language runtime and environment, and all of the code build atop it.

The idea that you could "just add threads" to PHP and make it
"enterprise-ready" is so naive it's mind boggling.

--Larry Garfield



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

--00163646bd9a2aefb3048283de7b--

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

When looking at PHP as used in enterprise class applications, we can see
the following happening. Let imagine that we have a site that gets a
1000 requests per second. That seems to be a good candidate for
threading so as to be able to handle the 1000 requests per second. The
site runs PHP and Apache. Well, what happens? Each request coming in is
handed of to a separate instance of Apache. Thus the site would be able
to process many requests simultaneously. It looks as if parallel
computing is taking place here, which looks much like threading. Even
though PHP itself does not know about threads, and does not need to, I
think, the whole process of handling the 1000 requests per second uses
parallel computing. There are no performance bottle-necks here. Teus.

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

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

On Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote:
> The response time, max 5 seconds, will be tested on local gigabit LAN
> to ensure the adequate response (optimized DB & code & proper
> hardware) without worrying about users' connection limit and site's
> upload bandwidth limit (which can easily rectify). Then thereafter
> will be doing stress test of about 10 concurrent users. As for the
> major queries, that's where threads come in, IMO, because those
> queries depend on 1 primary parameter (category ID) and 1 secondary
> parameter (language ID). This particular site starts with 500
> products about 15 categories, without many of those mentioned filters,
> later grew to its current state.
>=20
The bottle neck looking at speed in this example seems to be the
database backend, not PHP. What would be needed is a fast database, and
SQL queries optimized for speed. Teus.


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

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

Most if that stuff should only be in the db as a reference and when
editing te lists. The actual user acessed data should sit in simple
XML files that can be passed to the client, broken out by category or
prod line. The reasons are simple, database access time is going to
suck, no matter what you are running. And why would you ever need to
run translation real time. I can tell you from persoanl experience
that such solution totally blows. I lost that battle at work and the
current solution build every field on the fly each time with
translation ( supporting 12 languages) and it's damn slow. Cache out
whatever you can, to an in memory cache or to the file system. Let the
web server do it's job of serving files, not processing upteen little
bits of data from a db.

It's about design, from all I've seen, threading introduces about as
many challenges as problems it solves.

Bastien

Sent from my iPod

On Mar 23, 2010, at 9:17 PM, Tommy Pham wrote:

> Let's go back to my 1st e-commerce example. The manufacturers list is
> about 3,700. The categories is about about 2,400. The products list
> is right now at 500,000 and expected to be around 750,000. The site
> is only in English. The store owner wants to expand and be I18n:
> Chinese, French, German, Korean, Spanish. You see how big and complex
> that database gets? The store owners want to have this happens when a
> customer clicks on a category:
>
> * show all subcategories for that category, if any
> * show all products for that category, if any,
> * show all manufacturers, used as filtering, for that category and
> subcategories
> * show price range filter for that category
> * show features & specifications filter for that category
> * show 10 top sellers for that category and related subcategories
> * the shopper can then select/deselect any of those filters and
> ability to sort by manufacturers, prices, user rating, popularity
> (purchased quantity)
> * have the ability to switch to another language translation on the
> fly
> * from the moment the shopper click on a link, the response time (when
> web browser saids "Done" in the status bar) is 5 seconds or less.
> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>
> Now show me a website that meets those requirements and uses PHP, I'll
> be glad to support your argument about PHP w/o threads :) BTW, this
> is not even enterprise requirement. I may have another possible
> project where # products is over 10 million easily. With similar
> requirements when the user click on category. Do you think this site,
> which currently isn't, can run on PHP?
>
> Regards,
> Tommy
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

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

On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop wrote:
> When looking at PHP as used in enterprise class applications, we can see
> the following happening. Let imagine that we have a site that gets a
> 1000 requests per second. That seems to be a good candidate for
> threading so as to be able to handle the 1000 requests per second. The
> site runs PHP and Apache. Well, what happens? Each request coming in is
> handed of to a separate instance of Apache. Thus the site would be able
> to process many requests simultaneously. It looks as if parallel
> computing is taking place here, which looks much like threading. Even
> though PHP itself does not know about threads, and does not need to, I
> think, the whole process of handling the 1000 requests per second uses
> parallel computing. There are no performance bottle-necks here. Teus.
>

# of requests / second can be solved by load balancers/clusters. What
about the multiple answers for a simple request per user as in my
example? How you would solve that if not by threading? Amazon has
about 30 million products and they have filters similar to what I
mentioned. But when clicking on one of the I18n site at the bottom,
you're taken to another server, which looks like it uses a different
DB back end (I could be wrong) and you don't get instant translation
of the category you're looking at. Their response time is about 3
seconds on my 10mbs (not cable) download. As for what programming
language they use...

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

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

On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote:
> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop
wrote:
> > When looking at PHP as used in enterprise class applications, we can see
> > the following happening. Let imagine that we have a site that gets a
> > 1000 requests per second. That seems to be a good candidate for
> > threading so as to be able to handle the 1000 requests per second. The
> > site runs PHP and Apache. Well, what happens? Each request coming in is
> > handed of to a separate instance of Apache. Thus the site would be able
> > to process many requests simultaneously. It looks as if parallel
> > computing is taking place here, which looks much like threading. Even
> > though PHP itself does not know about threads, and does not need to, I
> > think, the whole process of handling the 1000 requests per second uses
> > parallel computing. There are no performance bottle-necks here. Teus.
>
> # of requests / second can be solved by load balancers/clusters. What
> about the multiple answers for a simple request per user as in my
> example? How you would solve that if not by threading? Amazon has
> about 30 million products and they have filters similar to what I
> mentioned. But when clicking on one of the I18n site at the bottom,
> you're taken to another server, which looks like it uses a different
> DB back end (I could be wrong) and you don't get instant translation
> of the category you're looking at. Their response time is about 3
> seconds on my 10mbs (not cable) download. As for what programming
> language they use...

Honestly, how WOULD you solve that with threading? You describe a page that
needs to be generated that has a half-dozen queries against the database
ranging from simple to moderately complex, some of which are site-generic and
some are user-specific.

How does one solve that with threading?

1) Run the site-generic queries once and cache them in memory and let other
threads just use that query result. You can do that without threads. Just
render that part of the page and cache that string to disk, to the database,
or to memcache. If the memecache server is on the same box then it should be
identical to the threading version, performance-wise. (Give or take VM
considerations.)

2) Push the user-specific DB queries to separate threads so they can run in
parallel. All that does is push the hard work off onto the DB server, which is
still running the same number of queries. And PHP can't respond until all of
the queries finish anyway, and the DB server will respond no faster, so you're
really gaining nothing.

You keep saying "how would you solve this without threads?" as if they're some
magical speed fairy dust. Given the scenario you describe, I don't even see
how threads would buy you anything at all.

Where threads would be useful is for lots of very small writes on rapidly
changing data. I would never want to write, say, the World of Warcraft
servers without threading and a persistent runtime, but then I wouldn't want
to write them in PHP to begin with.

Insert that old saying about hammers and nails here.

--Larry Garfield

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

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

On Tue, Mar 23, 2010 at 9:13 PM, Phpster wrote:
> Most if that stuff should only be in the db as a reference and when editi=
ng
> te lists. The actual user acessed data should sit in simple XML files tha=
t
> can be passed to the client, broken out by category or prod line. The
> reasons are simple, database access time is going to suck, no matter what
> you are running. And why would you ever need to run translation real time=
.. I
> can tell you from persoanl experience that such solution totally blows. I
> lost that battle at work and the current solution build every field on th=
e
> fly each time with translation ( supporting 12 languages) and it's damn
> slow. Cache out whatever you can, to an in memory cache or to the file
> system. Let the web server do it's job of serving files, not processing
> upteen little bits of data from a db.
>
> It's about design, from all I've seen, threading introduces about as many
> challenges as problems it solves.
>
> Bastien

If having the products info in categorized XML files as you mention,
why the need for DB then? What about some product name changes to
correctly describe the product without the informed shopper having to
read the description/specifications? The translation is fetched from
the DB and not using any 3rd party software translation on the fly.

>
> Sent from my iPod
>
> On Mar 23, 2010, at 9:17 PM, Tommy Pham wrote:
>
>> Let's go back to my 1st e-commerce example.  The manufacturers list=
is
>> about 3,700.  The categories is about about 2,400.  The produc=
ts list
>> is right now at 500,000 and expected to be around 750,000.  The sit=
e
>> is only in English.  The store owner wants to expand and be I18n:
>> Chinese, French, German, Korean, Spanish.  You see how big and comp=
lex
>> that database gets?  The store owners want to have this happens whe=
n a
>> customer clicks on a category:
>>
>> * show all subcategories for that category, if any
>> * show all products for that category, if any,
>> * show all manufacturers, used as filtering, for that category and
>> subcategories
>> * show price range filter for that category
>> * show features & specifications filter for that category
>> * show 10 top sellers for that category and related subcategories
>> * the shopper can then select/deselect any of those filters and
>> ability to sort by manufacturers, prices, user rating, popularity
>> (purchased quantity)
>> * have the ability to switch to another language translation on the fly
>> * from the moment the shopper click on a link, the response time (when
>> web browser saids "Done" in the status bar) is 5 seconds or less.
>> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>>
>> Now show me a website that meets those requirements and uses PHP, I'll
>> be glad to support your argument about PHP w/o threads :)  BTW, thi=
s
>> is not even enterprise requirement.  I may have another possible
>> project where # products is over 10 million easily.  With similar
>> requirements when the user click on category.  Do you think this si=
te,
>> which currently isn't, can run on PHP?
>>
>> Regards,
>> Tommy
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

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

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

On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote:
> # of requests / second can be solved by load balancers/clusters. What
> about the multiple answers for a simple request per user as in my
> example? How you would solve that if not by threading? Amazon has
> about 30 million products and they have filters similar to what I
> mentioned. But when clicking on one of the I18n site at the bottom,
> you're taken to another server, which looks like it uses a different
> DB back end (I could be wrong) and you don't get instant translation
> of the category you're looking at. Their response time is about 3
> seconds on my 10mbs (not cable) download. As for what programming
> language they use...
>=20

Well, the multiple answers for a simple request per user as in your
example, seem to be a lot of information to display all on one page, and
present all that information to the user in one request. I would
probably resolve it, IMHO, by using pagers. That is, only part of the
information is shown to the user at one time, and the user can page
through that information so as to get to other bits of information. If
only part is shown, then the database query becomes so much faster
(hopefully), and PHP still can do all of it in one thread.

A PHP application, by the nature of PHP, consists of small page requests
to be done at one time, rather than move a lot of information around per
request. Thinking the PHP-way requires some study because, as said, the
information is presented or moved about in small chunks. Desktop
applications, and probably Java web applications (I have no experience
with Java but have read up on it a little) work differently. A
successful PHP application is redesigned from the ground up, rather than
remorphing a Java or other desktop application in PHP without changing
the design principles.

The key to makign your eCommerce application snappy, is, I think, not
threading, but optimization of database queries. And another key is that
less information presented to the user is usually clearer to the user,
and thus they feel better at the site, and would return sooner to buy
something. The real head-ache here and the difficult part is: How to
design a clear and clean interface for the user. It's not threading.

Teus.


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

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

On Tue, Mar 23, 2010 at 9:49 PM, Larry Garfield wr=
ote:
> On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote:
>> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop
> wrote:
>> > When looking at PHP as used in enterprise class applications, we can s=
ee
>> > the following happening. Let imagine that we have a site that gets a
>> > 1000 requests per second. That seems to be a good candidate for
>> > threading so as to be able to handle the 1000 requests per second. The
>> > site runs PHP and Apache. Well, what happens? Each request coming in i=
s
>> > handed of to a separate instance of Apache. Thus the site would be abl=
e
>> > to process many requests simultaneously. It looks as if parallel
>> > computing is taking place here, which looks much like threading. Even
>> > though PHP itself does not know about threads, and does not need to, I
>> > think, the whole process of handling the 1000 requests per second uses
>> > parallel computing. There are no performance bottle-necks here. Teus.
>>
>> # of requests / second can be solved by load balancers/clusters.  W=
hat
>> about the multiple answers for a simple request per user as in my
>> example?  How you would solve that if not by threading?  Amazo=
n has
>> about 30 million products and they have filters similar to what I
>> mentioned.  But when clicking on one of the I18n site at the bottom=
,
>> you're taken to another server, which looks like it uses a different
>> DB back end (I could be wrong) and you don't get instant translation
>> of the category you're looking at.  Their response time is about 3
>> seconds on my 10mbs (not cable) download.  As for what programming
>> language they use...
>
> Honestly, how WOULD you solve that with threading?  You describe a p=
age that
> needs to be generated that has a half-dozen queries against the database
> ranging from simple to moderately complex, some of which are site-generic=
and
> some are user-specific.
>
> How does one solve that with threading?
>
> 1) Run the site-generic queries once and cache them in memory and let oth=
er
> threads just use that query result.  You can do that without threads=
..  Just
> render that part of the page and cache that string to disk, to the databa=
se,
> or to memcache.  If the memecache server is on the same box then it =
should be
> identical to the threading version, performance-wise.  (Give or take=
VM
> considerations.)
>
> 2) Push the user-specific DB queries to separate threads so they can run =
in
> parallel.  All that does is push the hard work off onto the DB serve=
r, which is
> still running the same number of queries.  And PHP can't respond unt=
il all of
> the queries finish anyway, and the DB server will respond no faster, so y=
ou're
> really gaining nothing.
>
> You keep saying "how would you solve this without threads?" as if they're=
some
> magical speed fairy dust.  Given the scenario you describe, I don't =
even see
> how threads would buy you anything at all.
>
> Where threads would be useful is for lots of very small writes on rapidly
> changing data.  I would never want to write, say, the World of Warcr=
aft
> servers without threading and a persistent runtime, but then I wouldn't w=
ant
> to write them in PHP to begin with.
>
> Insert that old saying about hammers and nails here.
>
> --Larry Garfield
>

The difference is doing all those queries in serial operations (one
after another) versus parallel operations (threads). Instead of
waiting, for example, about .05 to .25 sec for each of those queries,
the total wait time would be diminishes since each thread would
execute a query. Either way, the DB is still doing the required total
work. Difference is serial & parallel operations as I iterated
several times. Being running in parallel, the web browser will be
getting the required info faster since PHP is able to get all the info
faster.

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

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

On Tue, Mar 23, 2010 at 9:55 PM, Teus Benschop wro=
te:
> On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote:
>> # of requests / second can be solved by load balancers/clusters.  W=
hat
>> about the multiple answers for a simple request per user as in my
>> example?  How you would solve that if not by threading?  Amazo=
n has
>> about 30 million products and they have filters similar to what I
>> mentioned.  But when clicking on one of the I18n site at the bottom=
,
>> you're taken to another server, which looks like it uses a different
>> DB back end (I could be wrong) and you don't get instant translation
>> of the category you're looking at.  Their response time is about 3
>> seconds on my 10mbs (not cable) download.  As for what programming
>> language they use...
>>
>
> Well, the multiple answers for a simple request per user as in your
> example, seem to be a lot of information to display all on one page, and
> present all that information to the user in one request. I would
> probably resolve it, IMHO, by using pagers. That is, only part of the

Pagers are needed when there's a lot of products to display. But
using the filters and show them is different. Look at Amazon (not
endorsing it). Click any category. You'll see what I mean by the
filters (manufacturers, price range, subcategories, etc) and the
display requirements (specials, bestsellers) as I mentioned. They
also have other things, like shoppers' discussions, on that page too.
Think about how many queries they have to run for all that info to
show based on a simple request of a 'category'. Then time the
response time.

> information is shown to the user at one time, and the user can page
> through that information so as to get to other bits of information. If
> only part is shown, then the database query becomes so much faster
> (hopefully), and PHP still can do all of it in one thread.
>
> A PHP application, by the nature of PHP, consists of small page requests
> to be done at one time, rather than move a lot of information around per
> request. Thinking the PHP-way requires some study because, as said, the
> information is presented or moved about in small chunks. Desktop
> applications, and probably Java web applications (I have no experience
> with Java but have read up on it a little) work differently. A
> successful PHP application is redesigned from the ground up, rather than
> remorphing a Java or other desktop application in PHP without changing
> the design principles.
>
> The key to makign your eCommerce application snappy, is, I think, not
> threading, but optimization of database queries. And another key is that
> less information presented to the user is usually clearer to the user,
> and thus they feel better at the site, and would return sooner to buy
> something. The real head-ache here and the difficult part is: How to
> design a clear and clean interface for the user. It's not threading.
>
> Teus.
>

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

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

Tommy Pham wrote:

> The company started small. As their business grows because they have=

> products & services that do not exist in the marketplace, their
> hardware are already growing along side with it, (load balancers,
> clusters). So then your solution is buy bigger/more boxes? What if
> the their server room is filled and already using recent hardware.

Same answer - buy a bigger box (i.e. serverroom). I would certainly
also start a redesign from the ground up, but to solve the immediate
problem, get more hardware.=20

> Their current business needs doesn't need to move to a bigger
> building. What then? Hire data center's services? What if they want=

> to protect their proprietary break through products and services?

Rent space and maybe hardware. That's what most businesses do.=20

> What about unnecessary additional total cost of ownership (licenses,
> power consumption, etc...) for more/bigger boxes, even if they have
> available space, that could be avoided by just implementing threads?

If you believe threading is such a silver bullet, I really think you
need to reconsider. This business has already invested in more
hardware to satisfy demand, so the application has some scalability -
presumably achieved by running multiple processes. Threads have some
advantages over processes, but when your design doesn't take that into
account anyway, why do you need threads?

[snip]
> In summary, you're saying that PHP can not grow/evolve with=20
> business right?=20

Certainly not. PHP is just a language, like most other programming
languages, it doesn't grow nor does it evolve a lot. (the OOP paradigm=

is an example of where PHP evolved).=20
I'm saying that a back-of-a-fag-packet design won't grow nor evolve ver=
y
well, and its inevitable shortcomings will not be solved by bolting
on "threading".

> If the company started small and want to use available open source
> solutions, then grow quickly because of their unique and quality
> products and services, and become enterprise level with-in a few
> years, what then? Slow down business growth just so that IT can
> migrate everything to another language? Of all the enterprise
> applications I've seen, they used threads.=20

Tommy, that's not about the language, that's a design issue. Run PHP i=
n
multiple processes, and you've got the parallelism you seem to seek.=20=


/Per

--=20
Per Jessen, Zürich (6.8°C)


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

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

stop bashing the people who DO have a use for threading and other
advanced concepts eh.

just because you don't have a use for it, it shouldn't be included?!
kinda arrogant.

also kinda arrogant: how do you know the guy needing threading is not
working on projects many times as complex as your own projects??


On Wed, Mar 24, 2010 at 12:33 AM, Per Jessen wrote:
> Tommy Pham wrote:
>
>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote:
>>>
>>> Use the right tool for the right job - PHP is a scripting/interpreted
>>> language, it does not need threading (IMO of course).
>>>
>>>
>>> --
>>> Per Jessen, Zürich (9.4°C)
>>>
>>>
>>
>> I couldn't agree more. =A0But here's a real life example. =A0Your client
>> has a forum and is using phpbb for their in house use. =A0They also have
>> an in house custom PHP app, integrated with phpbb, built to suit their
>> needs. =A0Now they want to implement some kind of CMS. =A0You come in an=
d
>> implemented a PHP based CMS to integrate into their existing
>> applications. =A0Then you realize something troublesome, you have a
>> performance issue where it could be resolved by implementing thread.
>> What are you going to do?
>
> The standard, mature, experienced answer is - buy a bigger box.
>
> [snip]
>> What do you think the client's response is when their need for the
>> solution requires a short time frame of, if not immediate,
>> implementation?
>
> There are no immediate solutions to immediate performance problems. =A0If
> you have a poor design that restricts your throughput, you can 1) throw
> hardware at it or 2) change the design. =A0At some point you'll hit yet
> another limit with 1), and you are forced back to 2). =A0Somewhere along
> the line the original designer has presumably left or been made to.
>
>
> /Per
>
> --
> Per Jessen, Zürich (7.5°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

throw more hardware at it?

how about you not butt into my business and how i save costs eh..

On Wed, Mar 24, 2010 at 9:31 AM, Per Jessen wrote:
> Tommy Pham wrote:
>
>> The company started small. =A0As their business grows because they have
>> products & services that do not exist in the marketplace, their
>> hardware are already growing along side with it, (load balancers,
>> clusters). =A0So then your solution is buy bigger/more boxes? =A0What if
>> the their server room is filled and already using recent hardware.
>
> Same answer - buy a bigger box (i.e. serverroom). =A0I would certainly
> also start a redesign from the ground up, but to solve the immediate
> problem, get more hardware.
>
>> Their current business needs doesn't need to move to a bigger
>> building. =A0What then? Hire data center's services? =A0What if they wan=
t
>> to protect their proprietary break through products and services?
>
> Rent space and maybe hardware. That's what most businesses do.
>
>> What about unnecessary additional total cost of ownership (licenses,
>> power consumption, etc...) for more/bigger boxes, even if they have
>> available space, that could be avoided by just implementing threads?
>
> If you believe threading is such a silver bullet, I really think you
> need to reconsider. =A0This business has already invested in more
> hardware to satisfy demand, so the application has some scalability -
> presumably achieved by running multiple processes. =A0Threads have some
> advantages over processes, but when your design doesn't take that into
> account anyway, why do you need threads?
>
> [snip]
>> In summary, you're saying that PHP can not grow/evolve with
>> business right?
>
> Certainly not. =A0PHP is just a language, like most other programming
> languages, it doesn't grow nor does it evolve a lot. =A0(the OOP paradigm
> is an example of where PHP evolved).
> I'm saying that a back-of-a-fag-packet design won't grow nor evolve very
> well, and its inevitable shortcomings will not be solved by bolting
> on "threading".
>
>> If the company started small and want to use available open source
>> solutions, then grow quickly because of their unique and quality
>> products and services, and become enterprise level with-in a few
>> years, what then? =A0Slow down business growth just so that IT can
>> migrate everything to another language? Of all the enterprise
>> applications I've seen, they used threads.
>
> Tommy, that's not about the language, that's a design issue. =A0Run PHP i=
n
> multiple processes, and you've got the parallelism you seem to seek.
>
> /Per
>
> --
> Per Jessen, Zürich (6.8°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

and btw, complexity of design can go up considerably when you have to
deal with more than 1 php and 1 mysql server, because the language
forces inefficient constructs _and_ is "stuck on 1 server"....

On Wed, Mar 24, 2010 at 9:36 AM, Rene Veerman wrote:
> throw more hardware at it?
>
> how about you not butt into my business and how i save costs eh..
>
> On Wed, Mar 24, 2010 at 9:31 AM, Per Jessen wrote:
>> Tommy Pham wrote:
>>
>>> The company started small. =A0As their business grows because they have
>>> products & services that do not exist in the marketplace, their
>>> hardware are already growing along side with it, (load balancers,
>>> clusters). =A0So then your solution is buy bigger/more boxes? =A0What i=
f
>>> the their server room is filled and already using recent hardware.
>>
>> Same answer - buy a bigger box (i.e. serverroom). =A0I would certainly
>> also start a redesign from the ground up, but to solve the immediate
>> problem, get more hardware.
>>
>>> Their current business needs doesn't need to move to a bigger
>>> building. =A0What then? Hire data center's services? =A0What if they wa=
nt
>>> to protect their proprietary break through products and services?
>>
>> Rent space and maybe hardware. That's what most businesses do.
>>
>>> What about unnecessary additional total cost of ownership (licenses,
>>> power consumption, etc...) for more/bigger boxes, even if they have
>>> available space, that could be avoided by just implementing threads?
>>
>> If you believe threading is such a silver bullet, I really think you
>> need to reconsider. =A0This business has already invested in more
>> hardware to satisfy demand, so the application has some scalability -
>> presumably achieved by running multiple processes. =A0Threads have some
>> advantages over processes, but when your design doesn't take that into
>> account anyway, why do you need threads?
>>
>> [snip]
>>> In summary, you're saying that PHP can not grow/evolve with
>>> business right?
>>
>> Certainly not. =A0PHP is just a language, like most other programming
>> languages, it doesn't grow nor does it evolve a lot. =A0(the OOP paradig=
m
>> is an example of where PHP evolved).
>> I'm saying that a back-of-a-fag-packet design won't grow nor evolve very
>> well, and its inevitable shortcomings will not be solved by bolting
>> on "threading".
>>
>>> If the company started small and want to use available open source
>>> solutions, then grow quickly because of their unique and quality
>>> products and services, and become enterprise level with-in a few
>>> years, what then? =A0Slow down business growth just so that IT can
>>> migrate everything to another language? Of all the enterprise
>>> applications I've seen, they used threads.
>>
>> Tommy, that's not about the language, that's a design issue. =A0Run PHP =
in
>> multiple processes, and you've got the parallelism you seem to seek.
>>
>> /Per
>>
>> --
>> Per Jessen, Zürich (6.8°C)
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

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

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

Tommy Pham wrote:

> Let's go back to my 1st e-commerce example. The manufacturers list i=
s
> about 3,700. The categories is about about 2,400. The products list=

> is right now at 500,000 and expected to be around 750,000. The site
> is only in English. The store owner wants to expand and be I18n:
> Chinese, French, German, Korean, Spanish. You see how big and comple=
x
> that database gets?=20

No, not really. So you want to add five languages - if your applicatio=
n
is just half-way prepared for multiple languages, that's no big deal
(apart from pure translation effort), and a database with only 5
million rows is also no big deal. If that is causing you a performance=

problem, it is definitely solveable by 1) hardware and 2) database
optimization.=20

> * from the moment the shopper click on a link, the response time
> (when web browser saids "Done" in the status bar) is 5 seconds or
> less. Preferably 2-3 seconds. Will be using stopwatch for the timer.

Yes, 3 seconds used to be the maximum response time for an inter-active=

application. The web might have moved the goal posts a bit :-)

> Now show me a website that meets those requirements and uses PHP, I'l=
l
> be glad to support your argument about PHP w/o threads :)=20

Tommy, you neglected to say anything about the number of concurrent
users, but if you have e.g. 10.000, you will need enough hardware to
run the webserver and the database. A webserver for serving 10.000
concurrent clients I would run on multiple boxes with an LVS load
distribution mechanism in front. The 5 million row database is
storage-wise not a lot, but running 10.000 concurrent queries will be a=

significant challenge. MySql cluster comes to mind. Apart from that,
apache and mysql will do all the threading you need.=20


/Per

--=20
Per Jessen, Zürich (7.8°C)


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

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

Teus Benschop wrote:

> On Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote:
>> The response time, max 5 seconds, will be tested on local gigabit LA=
N
>> to ensure the adequate response (optimized DB & code & proper
>> hardware) without worrying about users' connection limit and site's
>> upload bandwidth limit (which can easily rectify). Then thereafter
>> will be doing stress test of about 10 concurrent users. As for the
>> major queries, that's where threads come in, IMO, because those
>> queries depend on 1 primary parameter (category ID) and 1 secondary
>> parameter (language ID). This particular site starts with 500
>> products about 15 categories, without many of those mentioned
>> filters, later grew to its current state.
>>=20
> The bottle neck looking at speed in this example seems to be the
> database backend, not PHP. What would be needed is a fast database,
> and SQL queries optimized for speed. Teus.
>=20

+1.



--=20
Per Jessen, Zürich (7.8°C)


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

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

Robert Cummings wrote:

> Yes, I do. There's nothing in your requirements above that sound
> particularly difficult for PHP to handle with a good design and lots
> of caching... and of course the right hardware. I think you're hung u=
p
> on the numbers a bit... those aren't very big numbers for a database.=


Yeah. Given a decent database machine, those 5 millions rows can be
kept in-core all the time.=20



--=20
Per Jessen, Zürich (7.8°C)


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

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

look per, i for one build systems designed to scale to popular levels.

that means that whatever i can squeeze out of a single machine will
save me money. quite a lot, coz as you know dedicated hosting gets
very expensive when you have to buy fast machines.

threading features and persistent shared memory _would_ decrease cost,
a lot, for any php app that wants to scale to popular levels.

i'd like to keep coding in php, and not have to switch languages
because my app got popular.

On Wed, Mar 24, 2010 at 9:46 AM, Per Jessen wrote:
> Robert Cummings wrote:
>
>> Yes, I do. There's nothing in your requirements above that sound
>> particularly difficult for PHP to handle with a good design and lots
>> of caching... and of course the right hardware. I think you're hung up
>> on the numbers a bit... those aren't very big numbers for a database.
>
> Yeah. =A0Given a decent database machine, those 5 millions rows can be
> kept in-core all the time.
>
>
>
> --
> Per Jessen, Zürich (7.8°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

Tommy Pham wrote:

> # of requests / second can be solved by load balancers/clusters. Wha=
t
> about the multiple answers for a simple request per user as in my
> example? How you would solve that if not by threading?=20

Ah, you're worried that running multiple sql queries sequentially will
cause the response time to be too long? Now we're getting to the crux
of the matter. My immediate thought is - if you can't optimize the
database any further, run multiple http requests, there are ways of
doing that. at.


--=20
Per Jessen, Zürich (7.9°C)


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

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

Per Jessen wrote:
> Teus Benschop wrote:
>
>> On Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote:
>>> The response time, max 5 seconds, will be tested on local gigabit LAN
>>> to ensure the adequate response (optimized DB& code& proper
>>> hardware) without worrying about users' connection limit and site's
>>> upload bandwidth limit (which can easily rectify). Then thereafter
>>> will be doing stress test of about 10 concurrent users. As for the
>>> major queries, that's where threads come in, IMO, because those
>>> queries depend on 1 primary parameter (category ID) and 1 secondary
>>> parameter (language ID). This particular site starts with 500
>>> products about 15 categories, without many of those mentioned
>>> filters, later grew to its current state.
>>>
>> The bottle neck looking at speed in this example seems to be the
>> database backend, not PHP. What would be needed is a fast database,
>> and SQL queries optimized for speed. Teus.
>
> +1.

Seconded ...
My own servers spend 75% of the time in firebird and 25% in apache/php, and when
I need some extra performance I just add a second machine for firebird with a
lot more memory. PHP is not the bottleneck and while the computer is 99.5% idle
anyway I don't see any need for threading any time soon.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

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

Rene Veerman wrote:
> and btw, complexity of design can go up considerably when you have to
> deal with more than 1 php and 1 mysql server, because the language
> forces inefficient constructs _and_ is "stuck on 1 server"....

Switch to a real database?
MySQL still needs to grow up as well :)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

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

jeez dude, you're assuming that all software problems are best solved
by a sql solution.
imo, they're NOT. example? any realtime system with real work to do.

please stop pretending you know the proper design of all software that
is made or yet has to be made.
both a ya.

On Wed, Mar 24, 2010 at 9:55 AM, Lester Caine wrote:
> Rene Veerman wrote:
>>
>> and btw, complexity of design can go up considerably when you have to
>> deal with more than 1 php and 1 mysql server, because the language
>> forces inefficient constructs _and_ is "stuck on 1 server"....
>
> Switch to a real database?
> MySQL still needs to grow up as well :)
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

Rene Veerman wrote:

> stop bashing the people who DO have a use for threading and other
> advanced concepts eh.

I'm not bashing anyone.=20

> just because you don't have a use for it, it shouldn't be included?!
> kinda arrogant.

Feel free to think so - I never said I don't have a use for it
(threading), I just said thread-support doesn't belong in PHP.=20

> also kinda arrogant: how do you know the guy needing threading is not=

> working on projects many times as complex as your own projects??

I don't care what he is working on. It has absolutely no bearing on the=

conversation. =20

Please stop top-posting, it's not good netiquette.=20


--=20
Per Jessen, Zürich (8.4°C)


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

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

yes you are bashing them (me included) imo

you say threading support doesnt belong in php; with that you're
determining what i may and may not do, even if i have given you good
reasons for it, that you chose to ignore.

i hope the php developers have more sense than you. i'm done
discussing this with you.

and i like top-posting. a lot.

you may wanna stop trying to change the ways of others, especially if
they don't interfere with what YOU may and may not do.

On Wed, Mar 24, 2010 at 10:02 AM, Per Jessen wrote:
> Rene Veerman wrote:
>
>> stop bashing the people who DO have a use for threading and other
>> advanced concepts eh.
>
> I'm not bashing anyone.
>
>> just because you don't have a use for it, it shouldn't be included?!
>> kinda arrogant.
>
> Feel free to think so - I never said I don't have a use for it
> (threading), I just said thread-support doesn't belong in PHP.
>
>> also kinda arrogant: how do you know the guy needing threading is not
>> working on projects many times as complex as your own projects??
>
> I don't care what he is working on. It has absolutely no bearing on the
> conversation.
>
> Please stop top-posting, it's not good netiquette.
>
>
> --
> Per Jessen, Zürich (8.4°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

--=-pSy4Avg7z50Pr5kaZdJn
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-03-24 at 10:00 +0200, Rene Veerman wrote:

> jeez dude, you're assuming that all software problems are best solved
> by a sql solution.
> imo, they're NOT. example? any realtime system with real work to do.
>
> please stop pretending you know the proper design of all software that
> is made or yet has to be made.
> both a ya.
>
> On Wed, Mar 24, 2010 at 9:55 AM, Lester Caine wrote:
> > Rene Veerman wrote:
> >>
> >> and btw, complexity of design can go up considerably when you have to
> >> deal with more than 1 php and 1 mysql server, because the language
> >> forces inefficient constructs _and_ is "stuck on 1 server"....
> >
> > Switch to a real database?
> > MySQL still needs to grow up as well :)
> >
> > --
> > Lester Caine - G8HFL
> > -----------------------------
> > Contact - http://lsces.co.uk/wiki/?page=contact
> > L.S.Caine Electronic Services - http://lsces.co.uk
> > EnquirySolve - http://enquirysolve.com/
> > Model Engineers Digital Workshop - http://medw.co.uk//
> > Firebird - http://www.firebirdsql.org/index.php
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>


But aren't you doing exactly that by saying that PHP needs threading and
that threading is the only way to achieve certain goals. I've watched
this thread go on quite a bit, and haven't seen a really good argument
that proves PHP needs threading when it can't be solved without it. PHP
is PHP. If it behaved exactly the same as all the other languages, what
would make it distinct against those others. One of it's main strenghts
is its simplicity I feel. If you added threading to the bag of tricks it
already has, you're getting into areas that make it more difficult to
pick up for beginners (and that's not to mention the technical elements
involved in actually adding threading to PHP) Currently the only other
'easy' language I know for beginners is ColdFusion, and that's just
horrible. You wouldn't want to be responsible for sending the newbies
down that path would you?! :p

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-pSy4Avg7z50Pr5kaZdJn--

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

--=-JKui+qooeeIRdzVhL/2C
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote:


>
> and i like top-posting. a lot.



Rene, please do stop posting. It is in the mailing list rules that you
should bottom post.

There is a reason for it. It helps with readability if everyone conforms
to the same practice, and the mailing archives online are easier to
digest also.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-JKui+qooeeIRdzVhL/2C--

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

Rene Veerman wrote:
> jeez dude, you're assuming that all software problems are best solved
> by a sql solution.
> imo, they're NOT. example? any realtime system with real work to do.
>
> please stop pretending you know the proper design of all software that
> is made or yet has to be made.
> both a ya.

I run real time systems for offices that count serving time in seconds. I know
currently where the bottlenecks are, and adding 'threading' to PHP is not a
solution. I fact adding much of the dross that has been added to PHP5 is
ACTUALLY slowing down performance. I have PHP5.3 and PHP5.2 running on similarly
loaded sites, and PHP5.2 is faster! I am just pointing out that on *MY* REAL
applications, the SQL element is a major part of the processing time, and yes
moving some of the table lookups to be hard coded arrays in PHP would make a
difference, but then complicates configurability, so keeping them in the
database makes life easier.

The proper design is the one that meets the customers requirements and gets the
bills paid. Processing the raw statistics required for my own sites is best done
away from PHP, so using the right tools for the job is the important thing?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

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

Rene Veerman wrote:

> look per, i for one build systems designed to scale to popular levels=
..
>=20
> that means that whatever i can squeeze out of a single machine will
> save me money. quite a lot, coz as you know dedicated hosting gets
> very expensive when you have to buy fast machines.

Well, at Hetzner in Nuernberg you can rent an EQ8 for EUR89/month. It
comes with bandwidth, 1.5Tb software RAID, 24Gb RAM and a EUR149 setup
cost. That's an Intel Core i7, so 2.6GHz quad core plus
hyper-threading, meaning 4 to 8 concurrent processes.=20

I've got four of the slightly smaller EQ4 running as backend mailserver=
s
handling up to about 3000 concurrent SMTP connections per box. Is that
what you call a popular level?=20



--=20
Per Jessen, Zürich (8.9°C)


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

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

--0015174768a2c0dc4c048287b6fa
Content-Type: text/plain; charset=ISO-8859-1

funny how i've been topposting for over a year here and the complaints start
when i tell some people not to butt into my business and choice of tools.


On Wed, Mar 24, 2010 at 10:11 AM, Ashley Sheridan
wrote:

> On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote:
>
> and i like top-posting. a lot.
>
>
>
> Rene, please do stop posting. It is in the mailing list rules that you
> should bottom post.
>
> There is a reason for it. It helps with readability if everyone conforms to
> the same practice, and the mailing archives online are easier to digest
> also.
>

i find 'm easier to digest with topposting.

>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--0015174768a2c0dc4c048287b6fa--

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

--=-3elW3s5vU13XquX+FSFO
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-03-24 at 10:28 +0200, Rene Veerman wrote:
> funny how i've been topposting for over a year here and the complaints
> start when i tell some people not to butt into my business and choice
> of tools.
>
>
>
> On Wed, Mar 24, 2010 at 10:11 AM, Ashley Sheridan
> wrote:
>
> On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote:
>
>
> > and i like top-posting. a lot.
>
>
>
>
>
> Rene, please do stop posting. It is in the mailing list rules
> that you should bottom post.
>
> There is a reason for it. It helps with readability if
> everyone conforms to the same practice, and the mailing
> archives online are easier to digest also.
>
> i find 'm easier to digest with topposting.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>


What you're actually saying is you find them easier to digest with both
top AND bottom posting, because the majority of the list bottom posts as
according to the rules, and you flaunt it deliberately for some reason.
You're asking people on the list to not make assumptions about your
applications and your 'need' for threading, and then blatantly ignore
the rules on posting assuming that because you find a mix of top and
bottom posting 'easier' to read, then so too will others.

I'm not suddenly bringing this into focus now because you've asked
people not to 'butt in' but because of the rude way you responded to Per
Jessen about top-posting. I'm just asking that please, for the sake of
clarity and readability, you bottom post to the list. If everyone does
the same thing, it makes it a lot easier.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-3elW3s5vU13XquX+FSFO--

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

popular : facebook youtube etc

and you're still trying to impose a toolset on me. i think it's not
strange to ask a programming language support basic hardware
architecture features as they evolve into mainstream.

On Wed, Mar 24, 2010 at 10:19 AM, Per Jessen wrote:
> Rene Veerman wrote:
>
>> look per, i for one build systems designed to scale to popular levels.
>>
>> that means that whatever i can squeeze out of a single machine will
>> save me money. quite a lot, coz as you know dedicated hosting gets
>> very expensive when you have to buy fast machines.
>
> Well, at Hetzner in Nuernberg you can rent an EQ8 for EUR89/month. It
> comes with bandwidth, 1.5Tb software RAID, 24Gb RAM and a EUR149 setup
> cost. =A0That's an Intel Core i7, so 2.6GHz quad core plus
> hyper-threading, meaning 4 to 8 concurrent processes.
>
> I've got four of the slightly smaller EQ4 running as backend mailservers
> handling up to about 3000 concurrent SMTP connections per box. Is that
> what you call a popular level?
>
>
>
> --
> Per Jessen, Zürich (8.9°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

so your systems represent all the software problems out there in the world?
or your experience does?

hard to believe.

On Wed, Mar 24, 2010 at 10:15 AM, Lester Caine wrote:
> Rene Veerman wrote:
>>
>> jeez dude, you're assuming that all software problems are best solved
>> by a sql solution.
>> imo, they're NOT. example? any realtime system with real work to do.
>>
>> please stop pretending you know the proper design of all software that
>> is made or yet has to be made.
>> both a ya.
>
> I run real time systems for offices that count serving time in seconds. I
> know currently where the bottlenecks are, and adding 'threading' to PHP is
> not a solution. I fact adding much of the dross that has been added to PHP5
> is ACTUALLY slowing down performance. I have PHP5.3 and PHP5.2 running on
> similarly loaded sites, and PHP5.2 is faster! I am just pointing out that on
> *MY* REAL applications, the SQL element is a major part of the processing
> time, and yes moving some of the table lookups to be hard coded arrays in
> PHP would make a difference, but then complicates configurability, so
> keeping them in the database makes life easier.
>
> The proper design is the one that meets the customers requirements and gets
> the bills paid. Processing the raw statistics required for my own sites is
> best done away from PHP, so using the right tools for the job is the
> important thing?
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

Rene Veerman wrote:

> yes you are bashing them (me included) imo
>=20
> you say threading support doesnt belong in php; with that you're
> determining what i may and may not do, even if i have given you good
> reasons for it, that you chose to ignore.

Well, call it what you like, I think I'm being perfectly civil.=20

By advocating that thread support does not belong in PHP, I am in no wa=
y
determining what you (or anyone else) may or may not do. You are a
free individual and free to choose the programming language and
paradigm that is best suited to your purposes.=20

Using your argument, one could also say that Kernighan and Ritchie
determined that "C should have no threading", just as the US DoD was
incredibly foresighted and decided we all should go multi-threaded when=

they gave Ada its tasks and rendezvous.=20


--=20
Per Jessen, Zürich (9.0°C)


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

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

--00151747af9e48a831048287e810
Content-Type: text/plain; charset=ISO-8859-1

talk to me about this some other time.

atm i'm having an argument with per and his kind about their very very
annoying behaviour of determining my toolset for me.
keeping a thread on topic is also ettiquette from the mailinglist rules eh?

you might wanna consider just how much it pisses me off to have strangers
determining my toolset and/or lifestyle for me.
that's why i got rude. no other reason.


On Wed, Mar 24, 2010 at 10:30 AM, Ashley Sheridan
wrote:

> On Wed, 2010-03-24 at 10:28 +0200, Rene Veerman wrote:
>
> funny how i've been topposting for over a year here and the complaints
> start when i tell some people not to butt into my business and choice of
> tools.
>
>
>
>
> On Wed, Mar 24, 2010 at 10:11 AM, Ashley Sheridan <
> ash@ashleysheridan.co.uk> wrote:
>
> On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote:
>
> and i like top-posting. a lot.
>
>
>
>
> Rene, please do stop posting. It is in the mailing list rules that you
> should bottom post.
>
> There is a reason for it. It helps with readability if everyone conforms to
> the same practice, and the mailing archives online are easier to digest
> also.
>
>
>
> i find 'm easier to digest with topposting.
>
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>
> What you're actually saying is you find them easier to digest with both top
> AND bottom posting, because the majority of the list bottom posts as
> according to the rules, and you flaunt it deliberately for some reason.
> You're asking people on the list to not make assumptions about your
> applications and your 'need' for threading, and then blatantly ignore the
> rules on posting assuming that because you find a mix of top and bottom
> posting 'easier' to read, then so too will others.
>
> I'm not suddenly bringing this into focus now because you've asked people
> not to 'butt in' but because of the rude way you responded to Per Jessen
> about top-posting. I'm just asking that please, for the sake of clarity and
> readability, you bottom post to the list. If everyone does the same thing,
> it makes it a lot easier.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--00151747af9e48a831048287e810--

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

On Wed, Mar 24, 2010 at 1:09 AM, Ashley Sheridan
wrote:
> On Wed, 2010-03-24 at 10:00 +0200, Rene Veerman wrote:
>
>> jeez dude, you're assuming that all software problems are best solved
>> by a sql solution.
>> imo, they're NOT. example? any realtime system with real work to do.
>>
>> please stop pretending you know the proper design of all software that
>> is made or yet has to be made.
>> both a ya.
>>
>> On Wed, Mar 24, 2010 at 9:55 AM, Lester Caine wrote:
>> > Rene Veerman wrote:
>> >>
>> >> and btw, complexity of design can go up considerably when you have to
>> >> deal with more than 1 php and 1 mysql server, because the language
>> >> forces inefficient constructs _and_ is "stuck on 1 server"....
>> >
>> > Switch to a real database?
>> > MySQL still needs to grow up as well :)
>> >
>> > --
>> > Lester Caine - G8HFL
>> > -----------------------------
>> > Contact - http://lsces.co.uk/wiki/?page=contact
>> > L.S.Caine Electronic Services - http://lsces.co.uk
>> > EnquirySolve - http://enquirysolve.com/
>> > Model Engineers Digital Workshop - http://medw.co.uk//
>> > Firebird - http://www.firebirdsql.org/index.php
>> >
>> > --
>> > PHP General Mailing List (http://www.php.net/)
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
>
> But aren't you doing exactly that by saying that PHP needs threading and
> that threading is the only way to achieve certain goals. I've watched
> this thread go on quite a bit, and haven't seen a really good argument
> that proves PHP needs threading when it can't be solved without it. PHP
> is PHP. If it behaved exactly the same as all the other languages, what
> would make it distinct against those others. One of it's main strenghts
> is its simplicity I feel. If you added threading to the bag of tricks it
> already has, you're getting into areas that make it more difficult to
> pick up for beginners (and that's not to mention the technical elements
> involved in actually adding threading to PHP) Currently the only other
> 'easy' language I know for beginners is ColdFusion, and that's just
> horrible. You wouldn't want to be responsible for sending the newbies
> down that path would you?! :p
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>

That's why I gave an analogy of AJAX earlier. You use AJAX yourself.
Do you use it for every project? Would you recommend AJAX to newbies?
When you do use AJAX, there is a slight difference in your app design
then when you don't use AJAX. That's the way I see threads. It's not
for every body nor for every project. But it would be great if it's
there when the need/requirement arises. And yes, coldfusion should be
phased out long ago...

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

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

On Wed, Mar 24, 2010 at 10:36 AM, Per Jessen wrote:

> By advocating that thread support does not belong in PHP, I am in no way
> determining what you (or anyone else) may or may not do. =A0You are a
> free individual and free to choose the programming language and
> paradigm that is best suited to your purposes.

right! that's saying "you're free to leave behind the tool you've
chosen for another one, because really, that tool should not start to
support things that i dont happen to have a use for."

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

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

Rene Veerman wrote:

> popular : facebook youtube etc
>=20

Rene, I must be missing something here. That sort of size implies
millions in advertising revenue, so why are we discussing how much
performance we can squeeze out of a single box? I mean, I'm all for
efficient use of system resources, but if I have a semi-scalable
application, it's a lot easier just getting another box than trying to
change the implementation language. OTOH, if my design is not
scalable, it's probably also easier to redo it than trying to change
the implementation language.

> and you're still trying to impose a toolset on me.=20

I didn't think I was - you're the one who seem to be fixed on PHP as th=
e
only solution, and advocating that it be enhanced to suit your
purposes.=20



--=20
Per Jessen, Zürich (9.2°C)


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

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

On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote:
> Rene Veerman wrote:
>
>> popular : facebook youtube etc
>>
>
> Rene, I must be missing something here. =A0That sort of size implies
> millions in advertising revenue, so why are we discussing how much
> performance we can squeeze out of a single box? =A0I mean, I'm all for
> efficient use of system resources, but if I have a semi-scalable
> application, it's a lot easier just getting another box than trying to
> change the implementation language. =A0OTOH, if my design is not
> scalable, it's probably also easier to redo it than trying to change
> the implementation language.

again:
a) you're determining the contents of my toolset, without it affecting
you at all. the way you want it php will degrade into a toy language.
b) i will aim for all possible decreases in development time and
operating costs during, not only in the grow phase but also in hard
economic times. any business person knows why.

>
>> and you're still trying to impose a toolset on me.
>
> I didn't think I was - you're the one who seem to be fixed on PHP as the
> only solution, and advocating that it be enhanced to suit your
> purposes.

no, php is just my toolset of choice, and i think it should grow with
the times and support threading and shared memory.
maybe even a few cool features to enable use-as-a-cloud.

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

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

Tommy Pham wrote:

> When you do use AJAX, there is a slight difference in your app design=

> then when you don't use AJAX. That's the way I see threads.=20

A threaded design makes for a lot more than a slight difference IMHO.=20=

Once you've said "threading", the next words in rapid succession are:
mutexes, semaphores, locking, spin-locks, signals, race conditions,
atomic updates, cache coherency, asynchronous IO etcetera. They are
all perfectly well-known but complex concepts, and I would always
choose C and/or assembler to work with those.=20



--=20
Per Jessen, Zürich (9.5°C)


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

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

Rene Veerman wrote:

> funny how i've been topposting for over a year here and the complaint=
s
> start when i tell some people not to butt into my business and choice=

> of tools.

Rene, the only reason I mentioned it was because your language was
becoming abusive and annoying. If it hadn't, I wouldn't have mentioned=

your equally annoying top-posting. I've been around for long enough to=

know that most top-posters will eventually see the light.=20


--=20
Per Jessen, Zürich (9.8°C)


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

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

exactly. the knock-on problems you mentioned are well solved and well
documented.
realtime programmers using threads have to get their heads around it
on their first realtime project.

i don't like doing my code in c(++), or worse; having to interface
between c(++) and php.
i chose php because my code can stay close to simple english that way.
what you're suggesting is highly intrusive in my work-style, one that
you're not affected by at all.
in fact if you make things more difficult for me, i have less time to
release opensource code of my own.

On Wed, Mar 24, 2010 at 10:59 AM, Per Jessen wrote:
> Tommy Pham wrote:
>
>> When you do use AJAX, there is a slight difference in your app design
>> then when you don't use AJAX. =A0That's the way I see threads.
>
> A threaded design makes for a lot more than a slight difference IMHO.
> Once you've said "threading", the next words in rapid succession are:
> mutexes, semaphores, locking, spin-locks, signals, race conditions,
> atomic updates, cache coherency, asynchronous IO etcetera. =A0They are
> all perfectly well-known but complex concepts, and I would always
> choose C and/or assembler to work with those.
>
>
>
> --
> Per Jessen, Zürich (9.5°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

Rene Veerman wrote:

> again:
> a) you're determining the contents of my toolset, without it affectin=
g
> you at all. the way you want it php will degrade into a toy language.=


Rene, it seems to me that you and I are advocating two opposite
positions on the topic of threading in PHP, so aren't we both trying to=

determine the contents of each others toolset?=20

> b) i will aim for all possible decreases in development time and
> operating costs during, not only in the grow phase but also in hard
> economic times. any business person knows why.

Given that the lifetime effort (=3Dcost) of any software project is
divided into 25% development and 75% maintenance, you really ought to
focus on the latter. If you want more performance at a minimal cost,
surely you should opt to write in a compiled language where you'll get
far more bang for the buck. =20


--=20
Per Jessen, Zürich (9.8°C)


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

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

On Wed, Mar 24, 2010 at 11:13 AM, Per Jessen wrote:
> Rene Veerman wrote:
>
>> again:
>> a) you're determining the contents of my toolset, without it affecting
>> you at all. the way you want it php will degrade into a toy language.
>
> Rene, it seems to me that you and I are advocating two opposite
> positions on the topic of threading in PHP, so aren't we both trying to
> determine the contents of each others toolset?
>

Per: that's EXACTLY the point.
You are determining it for me, i'm not for you.
Simply because you dont have to use the language features you atm
think you don't need in php.


>> b) i will aim for all possible decreases in development time and
>> operating costs during, not only in the grow phase but also in hard
>> economic times. any business person knows why.
>
> Given that the lifetime effort (=3Dcost) of any software project is
> divided into 25% development and 75% maintenance, you really ought to
> focus on the latter. =A0If you want more performance at a minimal cost,
> surely you should opt to write in a compiled language where you'll get
> far more bang for the buck.
>
zend? facebook compiler?

i'm staying with php coz the trend is towards jit compiling bro.

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

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

Heh, you guys are funny!

On 24 Mar 2010, at 08:58, Rene Veerman wrote:

> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote:
>> Rene Veerman wrote:
>>=20
>>> popular : facebook youtube etc
>>>=20
>>=20
>> Rene, I must be missing something here. That sort of size implies
>> millions in advertising revenue, so why are we discussing how much
>> performance we can squeeze out of a single box? I mean, I'm all for
>> efficient use of system resources, but if I have a semi-scalable
>> application, it's a lot easier just getting another box than trying =
to
>> change the implementation language. OTOH, if my design is not
>> scalable, it's probably also easier to redo it than trying to change
>> the implementation language.
>=20
> again:
> a) you're determining the contents of my toolset, without it affecting
> you at all. the way you want it php will degrade into a toy language.

And how exactly are you defining a toy language? If you want features =
like threading, why not switch to a language that already supports it?

> b) i will aim for all possible decreases in development time and
> operating costs during, not only in the grow phase but also in hard
> economic times. any business person knows why.

Yup, this is very good practice, but deciding that one particular tool =
is the only option is a fatal business decision. Use the right tool for =
the job!

What you're trying to do here is akin to taking a hammer and whittling a =
screwdriver in to the handle. It's ridiculously inefficient, and imo, =
pretty stupid.

>>> and you're still trying to impose a toolset on me.
>>=20
>> I didn't think I was - you're the one who seem to be fixed on PHP as =
the
>> only solution, and advocating that it be enhanced to suit your
>> purposes.
>=20
> no, php is just my toolset of choice, and i think it should grow with
> the times and support threading and shared memory.
> maybe even a few cool features to enable use-as-a-cloud.

PHP is a hammer, and a bloody good one at that, but you seem to want it =
to be a tool shed. Accept that it's a hammer, go visit a DIY store, find =
the right tool for the job and get on with your life!

The fact is that even if we all agree that PHP needs threading, and one =
or more people start working on putting it into the core, it will likely =
be many months before you see any sight of a working version, and even =
longer before you see a stable release.

-Stuart

--=20
http://stut.net/=

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

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

Rene Veerman wrote:

> what you're suggesting is highly intrusive in my work-style, one that=

> you're not affected by at all.

Hmm, you're the one suggesting a change, I'm suggesting no change. How=

can "no change" be intrusive?=20

> in fact if you make things more difficult for me, i have less time to=

> release opensource code of my own.

Well, we can't have that, so how about we stick to "no change", thereby=

not making anything more difficult for you. It will remain exactly as
difficult as it is today.


--=20
Per Jessen, Zürich (10.4°C)


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

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

If you added threading to the bag of tricks it already has, you're getting
into areas that make it more difficult to pick up for beginners (and that's
not to mention the technical elements involved in actually adding threading
to PHP) Currently the only other 'easy' language I know for beginners is
ColdFusion, and that's just horrible. You wouldn't want to be responsible
for sending the newbies down that path would you?! :p

Thanks,
Ash
http://www.ashleysheridan.co.uk

======================================

That's not a good argument against implementing threading, regardless of the
technical issues involved in making it work. There are plenty of more
advanced areas of php that beginners stay clear of. Just because threading
is available doesn't mean it will automatically be used or even considered
in most projects. I wrote C code for years in a large fairly complex banking
front-office system and only found a very few occasions where threading was
required to get the job done. In the majority of C and C++ code you find
very few examples of threading, either because it's not required (99.9% of
the time) or the coder didn't feel comfortable using it and found another
way to achieve the result. In the few occasions where I did use threading I
would say that most the time there was no other way of achieving the
required result. But the issues you need to solve with C are very different
to the issues you need to solve with php. I've spent more than 8 years
coding php and I haven't ever hit a brick wall because of the lack of
threading, but of course every project is different and I'm sure there are
situations out there where trying to work around the lack of threading can
cause major hassles. But as others have pointed out you use the right tools
for the job, and if php doesn't have what is required then use something
else.

Cheers
Arno



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

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

Rene Veerman wrote:

>>> b) i will aim for all possible decreases in development time and
>>> operating costs during, not only in the grow phase but also in hard=

>>> economic times. any business person knows why.
>>
>> Given that the lifetime effort (=3Dcost) of any software project is
>> divided into 25% development and 75% maintenance, you really ought t=
o
>> focus on the latter.  If you want more performance at a minimal=
cost,
>> surely you should opt to write in a compiled language where you'll
>> get far more bang for the buck.
>>
> zend? facebook compiler?

C, then assembler. C for productivity, assembler for raw speed. PHP
for prototyping and web frontends (to which it is very well suited
IMHO). (assembler is usually bad for both productivity and
maintenance, but if speed is paramount, well).



--=20
Per Jessen, Zürich (10.4°C)


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

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

php is not a hammer, its a programming language.

one that i feel needs to stay ahead of the computing trend if it is to
be considered a language for large scale applications.

but you nay-sayers here have convinced me; i'll be shopping for
another language with which to serve my applications and the weboutput
they produce..

thanks for opening my eyes and telling to abandon ship in time.


On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote:
> Heh, you guys are funny!
>
> On 24 Mar 2010, at 08:58, Rene Veerman wrote:
>
>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote:
>>> Rene Veerman wrote:
>>>
>>>> popular : facebook youtube etc
>>>>
>>>
>>> Rene, I must be missing something here. =A0That sort of size implies
>>> millions in advertising revenue, so why are we discussing how much
>>> performance we can squeeze out of a single box? =A0I mean, I'm all for
>>> efficient use of system resources, but if I have a semi-scalable
>>> application, it's a lot easier just getting another box than trying to
>>> change the implementation language. =A0OTOH, if my design is not
>>> scalable, it's probably also easier to redo it than trying to change
>>> the implementation language.
>>
>> again:
>> a) you're determining the contents of my toolset, without it affecting
>> you at all. the way you want it php will degrade into a toy language.
>
> And how exactly are you defining a toy language? If you want features lik=
e threading, why not switch to a language that already supports it?
>
>> b) i will aim for all possible decreases in development time and
>> operating costs during, not only in the grow phase but also in hard
>> economic times. any business person knows why.
>
> Yup, this is very good practice, but deciding that one particular tool is=
the only option is a fatal business decision. Use the right tool for the j=
ob!
>
> What you're trying to do here is akin to taking a hammer and whittling a =
screwdriver in to the handle. It's ridiculously inefficient, and imo, prett=
y stupid.
>
>>>> and you're still trying to impose a toolset on me.
>>>
>>> I didn't think I was - you're the one who seem to be fixed on PHP as th=
e
>>> only solution, and advocating that it be enhanced to suit your
>>> purposes.
>>
>> no, php is just my toolset of choice, and i think it should grow with
>> the times and support threading and shared memory.
>> maybe even a few cool features to enable use-as-a-cloud.
>
> PHP is a hammer, and a bloody good one at that, but you seem to want it t=
o be a tool shed. Accept that it's a hammer, go visit a DIY store, find the=
right tool for the job and get on with your life!
>
> The fact is that even if we all agree that PHP needs threading, and one o=
r more people start working on putting it into the core, it will likely be =
many months before you see any sight of a working version, and even longer =
before you see a stable release.
>
> -Stuart
>
> --
> http://stut.net/

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

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

unless the actual php development team would like to weigh in on this
matter of course.

yes, i do consider it that important.

these nay-sayers usually also lobby the dev-team to such extent that
these features would actually not make it into php.

On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote:
> php is not a hammer, its a programming language.
>
> one that i feel needs to stay ahead of the computing trend if it is to
> be considered a language for large scale applications.
>
> but you nay-sayers here have convinced me; i'll be shopping for
> another language with which to serve my applications and the weboutput
> they produce..
>
> thanks for opening my eyes and telling to abandon ship in time.
>
>
> On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote=
:
>> Heh, you guys are funny!
>>
>> On 24 Mar 2010, at 08:58, Rene Veerman wrote:
>>
>>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote:
>>>> Rene Veerman wrote:
>>>>
>>>>> popular : facebook youtube etc
>>>>>
>>>>
>>>> Rene, I must be missing something here. =A0That sort of size implies
>>>> millions in advertising revenue, so why are we discussing how much
>>>> performance we can squeeze out of a single box? =A0I mean, I'm all for
>>>> efficient use of system resources, but if I have a semi-scalable
>>>> application, it's a lot easier just getting another box than trying to
>>>> change the implementation language. =A0OTOH, if my design is not
>>>> scalable, it's probably also easier to redo it than trying to change
>>>> the implementation language.
>>>
>>> again:
>>> a) you're determining the contents of my toolset, without it affecting
>>> you at all. the way you want it php will degrade into a toy language.
>>
>> And how exactly are you defining a toy language? If you want features li=
ke threading, why not switch to a language that already supports it?
>>
>>> b) i will aim for all possible decreases in development time and
>>> operating costs during, not only in the grow phase but also in hard
>>> economic times. any business person knows why.
>>
>> Yup, this is very good practice, but deciding that one particular tool i=
s the only option is a fatal business decision. Use the right tool for the =
job!
>>
>> What you're trying to do here is akin to taking a hammer and whittling a=
screwdriver in to the handle. It's ridiculously inefficient, and imo, pret=
ty stupid.
>>
>>>>> and you're still trying to impose a toolset on me.
>>>>
>>>> I didn't think I was - you're the one who seem to be fixed on PHP as t=
he
>>>> only solution, and advocating that it be enhanced to suit your
>>>> purposes.
>>>
>>> no, php is just my toolset of choice, and i think it should grow with
>>> the times and support threading and shared memory.
>>> maybe even a few cool features to enable use-as-a-cloud.
>>
>> PHP is a hammer, and a bloody good one at that, but you seem to want it =
to be a tool shed. Accept that it's a hammer, go visit a DIY store, find th=
e right tool for the job and get on with your life!
>>
>> The fact is that even if we all agree that PHP needs threading, and one =
or more people start working on putting it into the core, it will likely be=
many months before you see any sight of a working version, and even longer=
before you see a stable release.
>>
>> -Stuart
>>
>> --
>> http://stut.net/
>

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

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

and if threading and shared memory aren't implemented, then hey, the
php dev team can build something else in that these naysayers DO need
eh...

lol...

On Wed, Mar 24, 2010 at 11:36 AM, Rene Veerman wrote:
> unless the actual php development team would like to weigh in on this
> matter of course.
>
> yes, i do consider it that important.
>
> these nay-sayers usually also lobby the dev-team to such extent that
> these features would actually not make it into php.
>
> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote=
:
>> php is not a hammer, its a programming language.
>>
>> one that i feel needs to stay ahead of the computing trend if it is to
>> be considered a language for large scale applications.
>>
>> but you nay-sayers here have convinced me; i'll be shopping for
>> another language with which to serve my applications and the weboutput
>> they produce..
>>
>> thanks for opening my eyes and telling to abandon ship in time.
>>
>>
>> On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrot=
e:
>>> Heh, you guys are funny!
>>>
>>> On 24 Mar 2010, at 08:58, Rene Veerman wrote:
>>>
>>>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote:
>>>>> Rene Veerman wrote:
>>>>>
>>>>>> popular : facebook youtube etc
>>>>>>
>>>>>
>>>>> Rene, I must be missing something here. =A0That sort of size implies
>>>>> millions in advertising revenue, so why are we discussing how much
>>>>> performance we can squeeze out of a single box? =A0I mean, I'm all fo=
r
>>>>> efficient use of system resources, but if I have a semi-scalable
>>>>> application, it's a lot easier just getting another box than trying t=
o
>>>>> change the implementation language. =A0OTOH, if my design is not
>>>>> scalable, it's probably also easier to redo it than trying to change
>>>>> the implementation language.
>>>>
>>>> again:
>>>> a) you're determining the contents of my toolset, without it affecting
>>>> you at all. the way you want it php will degrade into a toy language.
>>>
>>> And how exactly are you defining a toy language? If you want features l=
ike threading, why not switch to a language that already supports it?
>>>
>>>> b) i will aim for all possible decreases in development time and
>>>> operating costs during, not only in the grow phase but also in hard
>>>> economic times. any business person knows why.
>>>
>>> Yup, this is very good practice, but deciding that one particular tool =
is the only option is a fatal business decision. Use the right tool for the=
job!
>>>
>>> What you're trying to do here is akin to taking a hammer and whittling =
a screwdriver in to the handle. It's ridiculously inefficient, and imo, pre=
tty stupid.
>>>
>>>>>> and you're still trying to impose a toolset on me.
>>>>>
>>>>> I didn't think I was - you're the one who seem to be fixed on PHP as =
the
>>>>> only solution, and advocating that it be enhanced to suit your
>>>>> purposes.
>>>>
>>>> no, php is just my toolset of choice, and i think it should grow with
>>>> the times and support threading and shared memory.
>>>> maybe even a few cool features to enable use-as-a-cloud.
>>>
>>> PHP is a hammer, and a bloody good one at that, but you seem to want it=
to be a tool shed. Accept that it's a hammer, go visit a DIY store, find t=
he right tool for the job and get on with your life!
>>>
>>> The fact is that even if we all agree that PHP needs threading, and one=
or more people start working on putting it into the core, it will likely b=
e many months before you see any sight of a working version, and even longe=
r before you see a stable release.
>>>
>>> -Stuart
>>>
>>> --
>>> http://stut.net/
>>
>

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

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

--=-LYJx9s8Ke4qMDNr8HT2f
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-03-24 at 11:36 +0200, Rene Veerman wrote:

> these nay-sayers usually also lobby the dev-team to such extent that
> these features would actually not make it into php


I assume you have some proof for that accusation?

This thread has almost now turned into a platform for insulting each
other. Why do those few feel it necessary to do this on what could
otherwise be an intelligent discussion?

There are clearly two sides for this, although it does seem that the
majority of this list (or at least those that have participated in the
thread) are in favour of not including threading support in PHP.

Rene, clearly you feel strongly about this. Why don't you ask on the
internals list, as that is where you'll get the best response about
whether or not it is something that is feasible (although feasibility is
no indicator of whether it will be included or not)

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-LYJx9s8Ke4qMDNr8HT2f--

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

On 24 March 2010 10:38, Rene Veerman wrote:
> and if threading and shared memory aren't implemented, then hey, the
> php dev team can build something else in that these naysayers DO need
> eh...
>
> lol...

Do you have any idea how sad and pathetic you come across? I'm very
sorry to say this, but really, now's the time to stop posting and step
back, take a deep breath, then focus on something else.

> On Wed, Mar 24, 2010 at 11:36 AM, Rene Veerman wrote=
:
>> unless the actual php development team would like to weigh in on this
>> matter of course.
>>
>> yes, i do consider it that important.
>>
>> these nay-sayers usually also lobby the dev-team to such extent that
>> these features would actually not make it into php.
>>
>> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrot=
e:
>>> php is not a hammer, its a programming language.
>>>
>>> one that i feel needs to stay ahead of the computing trend if it is to
>>> be considered a language for large scale applications.
>>>
>>> but you nay-sayers here have convinced me; i'll be shopping for
>>> another language with which to serve my applications and the weboutput
>>> they produce..
>>>
>>> thanks for opening my eyes and telling to abandon ship in time.
>>>
>>>
>>> On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wro=
te:
>>>> Heh, you guys are funny!
>>>>
>>>> On 24 Mar 2010, at 08:58, Rene Veerman wrote:
>>>>
>>>>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote=
:
>>>>>> Rene Veerman wrote:
>>>>>>
>>>>>>> popular : facebook youtube etc
>>>>>>>
>>>>>>
>>>>>> Rene, I must be missing something here.  That sort of size impl=
ies
>>>>>> millions in advertising revenue, so why are we discussing how much
>>>>>> performance we can squeeze out of a single box?  I mean, I'm al=
l for
>>>>>> efficient use of system resources, but if I have a semi-scalable
>>>>>> application, it's a lot easier just getting another box than trying =
to
>>>>>> change the implementation language.  OTOH, if my design is not
>>>>>> scalable, it's probably also easier to redo it than trying to change
>>>>>> the implementation language.
>>>>>
>>>>> again:
>>>>> a) you're determining the contents of my toolset, without it affectin=
g
>>>>> you at all. the way you want it php will degrade into a toy language.
>>>>
>>>> And how exactly are you defining a toy language? If you want features =
like threading, why not switch to a language that already supports it?
>>>>
>>>>> b) i will aim for all possible decreases in development time and
>>>>> operating costs during, not only in the grow phase but also in hard
>>>>> economic times. any business person knows why.
>>>>
>>>> Yup, this is very good practice, but deciding that one particular tool=
is the only option is a fatal business decision. Use the right tool for th=
e job!
>>>>
>>>> What you're trying to do here is akin to taking a hammer and whittling=
a screwdriver in to the handle. It's ridiculously inefficient, and imo, pr=
etty stupid.
>>>>
>>>>>>> and you're still trying to impose a toolset on me.
>>>>>>
>>>>>> I didn't think I was - you're the one who seem to be fixed on PHP as=
the
>>>>>> only solution, and advocating that it be enhanced to suit your
>>>>>> purposes.
>>>>>
>>>>> no, php is just my toolset of choice, and i think it should grow with
>>>>> the times and support threading and shared memory.
>>>>> maybe even a few cool features to enable use-as-a-cloud.
>>>>
>>>> PHP is a hammer, and a bloody good one at that, but you seem to want i=
t to be a tool shed. Accept that it's a hammer, go visit a DIY store, find =
the right tool for the job and get on with your life!
>>>>
>>>> The fact is that even if we all agree that PHP needs threading, and on=
e or more people start working on putting it into the core, it will likely =
be many months before you see any sight of a working version, and even long=
er before you see a stable release.
>>>>
>>>> -Stuart
>>>>
>>>> --
>>>> http://stut.net/
>>>
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51


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

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

On 24 March 2010 10:38, Rene Veerman wrote:
> and if threading and shared memory aren't implemented, then hey, the
> php dev team can build something else in that these naysayers DO need
> eh...
>
> lol...
>

take a look at this -> http://nanoserv.si.kz/

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

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

-----Original Message-----
From: Rene Veerman [mailto:rene7705@gmail.com]
Sent: 24 March 2010 11:31 AM
Subject: Re: [PHP] Will PHP ever "grow up" and have threading?

thanks for opening my eyes and telling to abandon ship in time.

===============================

Bye, enjoy the swim...

Maybe by the time you get back to shore you'll realise how dumb it would be
if a sailor complained that his yatch didn't behave like a hovercraft, or
his passenger ship couldn't carry a million barrels of oil, or his tug boat
was useless at pulling a skier... Just how much (or little) development
experience do you have?

Cheers
Arno



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

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

--=-8HyG6DJB9j5Jb4FlsqHo
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-03-24 at 11:56 +0200, Rene Veerman wrote:

> sad and pathetic? how about "revealing".
>
> i can call your sad and pathetic for:
> - insisting on how others should do their work.
> - group-attacking your opposition, hoping to intimidate by outnumbering.
> - ignoring all valid explanations on why someone would like their fav
> tool to evolve with the market.
> - degrading into petty insults as a way to indicate i'm probably right
> about the claim that led you to petty insults.
>
> i can go on, but i just dont want another political battle on my hands.
>
> i'll find out what the php dev team thinks about this issue, and base
> my descision on whether or not to leave php behind, on that.
>
> but you people truly are worthy of some serious IRL larting for being
> such assholes who think they can determine the habits of others that
> don't affect them.
> i dont usually do this, have never done it to programmers; but you're
> lucky we're not in the same buiding.
> i'd get you to try and punch me, followed by a relatively nonviolent
> yet very public humiliation.
> THATS how strongly i feel about those who determine the lifestyle of
> others when it doesn't even affect them.
>
> Seriously, wars have erupted over this behaviour. The kind where axes
> and such are used to settle the issue.



Sorry Rene, but this has just made me lose all respect for you. I shan't
be too sad if you do jump ship.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-8HyG6DJB9j5Jb4FlsqHo--

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

sad and pathetic? how about "revealing".

i can call your sad and pathetic for:
- insisting on how others should do their work.
- group-attacking your opposition, hoping to intimidate by outnumbering.
- ignoring all valid explanations on why someone would like their fav
tool to evolve with the market.
- degrading into petty insults as a way to indicate i'm probably right
about the claim that led you to petty insults.

i can go on, but i just dont want another political battle on my hands.

i'll find out what the php dev team thinks about this issue, and base
my descision on whether or not to leave php behind, on that.

but you people truly are worthy of some serious IRL larting for being
such assholes who think they can determine the habits of others that
don't affect them.
i dont usually do this, have never done it to programmers; but you're
lucky we're not in the same buiding.
i'd get you to try and punch me, followed by a relatively nonviolent
yet very public humiliation.
THATS how strongly i feel about those who determine the lifestyle of
others when it doesn't even affect them.

Seriously, wars have erupted over this behaviour. The kind where axes
and such are used to settle the issue.


On Wed, Mar 24, 2010 at 11:43 AM, Peter Lind wrote=
:
> On 24 March 2010 10:38, Rene Veerman wrote:
>> and if threading and shared memory aren't implemented, then hey, the
>> php dev team can build something else in that these naysayers DO need
>> eh...
>>
>> lol...
>
> Do you have any idea how sad and pathetic you come across? I'm very
> sorry to say this, but really, now's the time to stop posting and step
> back, take a deep breath, then focus on something else.
>
>> On Wed, Mar 24, 2010 at 11:36 AM, Rene Veerman wrot=
e:
>>> unless the actual php development team would like to weigh in on this
>>> matter of course.
>>>
>>> yes, i do consider it that important.
>>>
>>> these nay-sayers usually also lobby the dev-team to such extent that
>>> these features would actually not make it into php.
>>>
>>> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wro=
te:
>>>> php is not a hammer, its a programming language.
>>>>
>>>> one that i feel needs to stay ahead of the computing trend if it is to
>>>> be considered a language for large scale applications.
>>>>
>>>> but you nay-sayers here have convinced me; i'll be shopping for
>>>> another language with which to serve my applications and the weboutput
>>>> they produce..
>>>>
>>>> thanks for opening my eyes and telling to abandon ship in time.
>>>>
>>>>
>>>> On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wr=
ote:
>>>>> Heh, you guys are funny!
>>>>>
>>>>> On 24 Mar 2010, at 08:58, Rene Veerman wrote:
>>>>>
>>>>>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrot=
e:
>>>>>>> Rene Veerman wrote:
>>>>>>>
>>>>>>>> popular : facebook youtube etc
>>>>>>>>
>>>>>>>
>>>>>>> Rene, I must be missing something here. =A0That sort of size implie=
s
>>>>>>> millions in advertising revenue, so why are we discussing how much
>>>>>>> performance we can squeeze out of a single box? =A0I mean, I'm all =
for
>>>>>>> efficient use of system resources, but if I have a semi-scalable
>>>>>>> application, it's a lot easier just getting another box than trying=
to
>>>>>>> change the implementation language. =A0OTOH, if my design is not
>>>>>>> scalable, it's probably also easier to redo it than trying to chang=
e
>>>>>>> the implementation language.
>>>>>>
>>>>>> again:
>>>>>> a) you're determining the contents of my toolset, without it affecti=
ng
>>>>>> you at all. the way you want it php will degrade into a toy language=
..
>>>>>
>>>>> And how exactly are you defining a toy language? If you want features=
like threading, why not switch to a language that already supports it?
>>>>>
>>>>>> b) i will aim for all possible decreases in development time and
>>>>>> operating costs during, not only in the grow phase but also in hard
>>>>>> economic times. any business person knows why.
>>>>>
>>>>> Yup, this is very good practice, but deciding that one particular too=
l is the only option is a fatal business decision. Use the right tool for t=
he job!
>>>>>
>>>>> What you're trying to do here is akin to taking a hammer and whittlin=
g a screwdriver in to the handle. It's ridiculously inefficient, and imo, p=
retty stupid.
>>>>>
>>>>>>>> and you're still trying to impose a toolset on me.
>>>>>>>
>>>>>>> I didn't think I was - you're the one who seem to be fixed on PHP a=
s the
>>>>>>> only solution, and advocating that it be enhanced to suit your
>>>>>>> purposes.
>>>>>>
>>>>>> no, php is just my toolset of choice, and i think it should grow wit=
h
>>>>>> the times and support threading and shared memory.
>>>>>> maybe even a few cool features to enable use-as-a-cloud.
>>>>>
>>>>> PHP is a hammer, and a bloody good one at that, but you seem to want =
it to be a tool shed. Accept that it's a hammer, go visit a DIY store, find=
the right tool for the job and get on with your life!
>>>>>
>>>>> The fact is that even if we all agree that PHP needs threading, and o=
ne or more people start working on putting it into the core, it will likely=
be many months before you see any sight of a working version, and even lon=
ger before you see a stable release.
>>>>>
>>>>> -Stuart
>>>>>
>>>>> --
>>>>> http://stut.net/
>>>>
>>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> Flickr: http://www.flickr.com/photos/fake51
> BeWelcome: Fake51
> Couchsurfing: Fake51
>
>

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

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

On 24 Mar 2010, at 09:36, Rene Veerman wrote:

> unless the actual php development team would like to weigh in on this
> matter of course.
>=20
> yes, i do consider it that important.
>=20
> these nay-sayers usually also lobby the dev-team to such extent that
> these features would actually not make it into php.

Frankly I don't give a crap whether threading is supported in PHP, it =
does everything I need it to do. If I need threading I use a language =
that supports it, like Python or C++.

I love the way you call us nay-sayers like it's supposed to be an =
insult. I follow the KISS principle to the nth, and as such threading in =
PHP doesn't make a lot of sense to me. I'm yet to come across a problem =
I couldn't solve with pure PHP, but when the need arises I have no issue =
mixing in a little C++, Python, Ruby, or whatever, to meet my =
performance and scalability goals. I go to the mountain, I don't sit =
there complaining that the mountain ain't moving in my direction!

My opinion, and that of most others who've weighed in, is that you're =
almost certainly looking at the problem from the wrong angle. What you =
haven't done is explicitly explain why you want threading to be =
supported. Give us a real example of why you think it should be =
supported and I guarantee we can come up with a way to get you what you =
want without requiring massive changes to the core of your chosen tool. =
And if we can't then you may actually convince us that threading would =
be a valuable feature to have available.

You mentioned Facebook as an example of a popular application. Are you =
aware that they only recently started using their compiler in =
production, and that prior to that they were happily running PHP to =
serve their front end without ever complaining that it didn't support =
threading? Even now, with hip-hop, individual requests are served in a =
single thread, so the language itself still doesn't support threading, =
and I don't hear them complaining that it's costing them a fortune. Why? =
Because it's not. And if it was they would have added it by now.

One final thing... if threading is this important to you, then I'm sure =
there are a number of developers who would happily add it in a fork of =
the core for suitable compensation. Once implemented it's possible the =
internals team would accept it for addition to the official version. If =
you really believe it has the potential to save you a butt-load of cash, =
the economics of paying for it should stack up.

Oh, and feel free to escalate this to anyone you please. Nobody cares. =
Threading has been discussed before, both on this list and on internals =
(Google can tell you all about it), and every time it's been dismissed =
because the cost-benefit calculations just don't add up.

> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman =
wrote:
>> php is not a hammer, its a programming language.
>>=20

And bravo on the metaphor appreciation failure. Love it!

-Stuart

--=20
http://stut.net/=

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

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

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"...

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

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

Rene Veerman wrote:

> unless the actual php development team would like to weigh in on this=

> matter of course.
>=20
> yes, i do consider it that important.
>=20
> these nay-sayers usually also lobby the dev-team to such extent that
> these features would actually not make it into php.

I for one will not be lobbying anyone in that regard. I've stated my
opinion and argued it, that's all.=20



--=20
Per Jessen, Zürich (11.2°C)


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

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

Stuart Dallas wrote:

> I love the way you call us nay-sayers like it's supposed to be an
> insult. I follow the KISS principle to the nth, and as such threading=

> in PHP doesn't make a lot of sense to me. I'm yet to come across a
> problem I couldn't solve with pure PHP, but when the need arises I
> have no issue mixing in a little C++, Python, Ruby, or whatever, to
> meet my performance and scalability goals. I go to the mountain, I
> don't sit there complaining that the mountain ain't moving in my
> direction!

+1.


--=20
Per Jessen, Zürich (11.2°C)


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

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

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"..=
..
>=20

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. =20



--=20
Per Jessen, Zürich (11.4°C)


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

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

On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote:
> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
>
>> unless the actual php development team would like to weigh in on this
>> matter of course.
>>
>> yes, i do consider it that important.
>>
>> these nay-sayers usually also lobby the dev-team to such extent that
>> these features would actually not make it into php.
>
> Frankly I don't give a crap whether threading is supported in PHP, it doe=
s everything I need it to do. If I need threading I use a language that sup=
ports it, like Python or C++.
>
> I love the way you call us nay-sayers like it's supposed to be an insult.=
I follow the KISS principle to the nth, and as such threading in PHP doesn=
't make a lot of sense to me. I'm yet to come across a problem I couldn't s=
olve with pure PHP, but when the need arises I have no issue mixing in a li=
ttle C++, Python, Ruby, or whatever, to meet my performance and scalability=
goals. I go to the mountain, I don't sit there complaining that the mounta=
in ain't moving in my direction!
>
> My opinion, and that of most others who've weighed in, is that you're alm=
ost certainly looking at the problem from the wrong angle. What you haven't=
done is explicitly explain why you want threading to be supported. Give us=
a real example of why you think it should be supported and I guarantee we =
can come up with a way to get you what you want without requiring massive c=
hanges to the core of your chosen tool. And if we can't then you may actual=
ly convince us that threading would be a valuable feature to have available=
..

I did give a real life example, ie e-commerce site mentioned earlier.
Amazon has the similar features of my example except they have about
30 million products without (i18n). Their I18n is different web
server & db & site layout which is completely different from my
example. Setting I18n aside, having the same features as my example
with about 30 million products to response in about 3 seconds is very
good. Even though my example only have about 750,000 products, the
translations for the requested languages makes it into 750,000 * 6 =3D
4,500,000 rows of product descriptions. This is e-commerce site not a
data warehouse/mining. What would happen then if the site has over
20,000,000 product skus with similar language translations for the
descriptions? 20,000,000 * 6 =3D ... big number to me...

>
> You mentioned Facebook as an example of a popular application. Are you aw=
are that they only recently started using their compiler in production, and=
that prior to that they were happily running PHP to serve their front end =
without ever complaining that it didn't support threading? Even now, with h=
ip-hop, individual requests are served in a single thread, so the language =
itself still doesn't support threading, and I don't hear them complaining t=
hat it's costing them a fortune. Why? Because it's not. And if it was they =
would have added it by now.
>
> One final thing... if threading is this important to you, then I'm sure t=
here are a number of developers who would happily add it in a fork of the c=
ore for suitable compensation. Once implemented it's possible the internals=
team would accept it for addition to the official version. If you really b=
elieve it has the potential to save you a butt-load of cash, the economics =
of paying for it should stack up.
>
> Oh, and feel free to escalate this to anyone you please. Nobody cares. Th=
reading has been discussed before, both on this list and on internals (Goog=
le can tell you all about it), and every time it's been dismissed because t=
he cost-benefit calculations just don't add up.
>
>> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrot=
e:
>>> php is not a hammer, its a programming language.
>>>
>
> And bravo on the metaphor appreciation failure. Love it!
>
> -Stuart
>
> --
> http://stut.net/
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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.  N=
ow
>> 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....

>
>
> --
> Per Jessen, Zürich (11.4°C)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

On 24 Mar 2010, at 10:24, Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas =
wrote:
>> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
>>=20
>>> unless the actual php development team would like to weigh in on =
this
>>> matter of course.
>>>=20
>>> yes, i do consider it that important.
>>>=20
>>> these nay-sayers usually also lobby the dev-team to such extent that
>>> these features would actually not make it into php.
>>=20
>> Frankly I don't give a crap whether threading is supported in PHP, it =
does everything I need it to do. If I need threading I use a language =
that supports it, like Python or C++.
>>=20
>> I love the way you call us nay-sayers like it's supposed to be an =
insult. I follow the KISS principle to the nth, and as such threading in =
PHP doesn't make a lot of sense to me. I'm yet to come across a problem =
I couldn't solve with pure PHP, but when the need arises I have no issue =
mixing in a little C++, Python, Ruby, or whatever, to meet my =
performance and scalability goals. I go to the mountain, I don't sit =
there complaining that the mountain ain't moving in my direction!
>>=20
>> My opinion, and that of most others who've weighed in, is that you're =
almost certainly looking at the problem from the wrong angle. What you =
haven't done is explicitly explain why you want threading to be =
supported. Give us a real example of why you think it should be =
supported and I guarantee we can come up with a way to get you what you =
want without requiring massive changes to the core of your chosen tool. =
And if we can't then you may actually convince us that threading would =
be a valuable feature to have available.
>=20
> I did give a real life example, ie e-commerce site mentioned earlier.
> Amazon has the similar features of my example except they have about
> 30 million products without (i18n). Their I18n is different web
> server & db & site layout which is completely different from my
> example. Setting I18n aside, having the same features as my example
> with about 30 million products to response in about 3 seconds is very
> good. Even though my example only have about 750,000 products, the
> translations for the requested languages makes it into 750,000 * 6 =3D
> 4,500,000 rows of product descriptions. This is e-commerce site not a
> data warehouse/mining. What would happen then if the site has over
> 20,000,000 product skus with similar language translations for the
> descriptions? 20,000,000 * 6 =3D ... big number to me...

How exactly will threading in PHP help with the size of the database? =
That makes no sense to me, please help me understand how you think =
threading will help in this scenario.

Database size issues are tackled with clustering, caching and DB =
optimisation. Threading in the language accessing the DB has no =
advantage here.

-Stuart

--=20
http://stut.net/=

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

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

On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote:
>
> Funny you should mention all that. =A0Let's say that you're longer with
> that company, either by direct employment or contract consultant.
> You've implemented C because you need 'thread'. =A0Now your replacement
> comes in and has no clue about C even though your replacement is a PHP
> guru. =A0How much headache is maintenance gonna be? =A0Scalability?
> Portability? wow....
>
Thanks for posting this before i had to.

+1, +1, +1...

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

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

On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote:
> On 24 Mar 2010, at 10:24, Tommy Pham wrote:
>> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote=
:
>>> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
>>>
>>>> unless the actual php development team would like to weigh in on this
>>>> matter of course.
>>>>
>>>> yes, i do consider it that important.
>>>>
>>>> these nay-sayers usually also lobby the dev-team to such extent that
>>>> these features would actually not make it into php.
>>>
>>> Frankly I don't give a crap whether threading is supported in PHP, it d=
oes everything I need it to do. If I need threading I use a language that s=
upports it, like Python or C++.
>>>
>>> I love the way you call us nay-sayers like it's supposed to be an insul=
t. I follow the KISS principle to the nth, and as such threading in PHP doe=
sn't make a lot of sense to me. I'm yet to come across a problem I couldn't=
solve with pure PHP, but when the need arises I have no issue mixing in a =
little C++, Python, Ruby, or whatever, to meet my performance and scalabili=
ty goals. I go to the mountain, I don't sit there complaining that the moun=
tain ain't moving in my direction!
>>>
>>> My opinion, and that of most others who've weighed in, is that you're a=
lmost certainly looking at the problem from the wrong angle. What you haven=
't done is explicitly explain why you want threading to be supported. Give =
us a real example of why you think it should be supported and I guarantee w=
e can come up with a way to get you what you want without requiring massive=
changes to the core of your chosen tool. And if we can't then you may actu=
ally convince us that threading would be a valuable feature to have availab=
le.
>>
>> I did give a real life example, ie e-commerce site mentioned earlier.
>> Amazon has the similar features of my example except they have about
>> 30 million products without (i18n).  Their I18n is different web
>> server & db & site layout which is completely different from my
>> example.  Setting I18n aside, having the same features as my exampl=
e
>> with about 30 million products to response in about 3 seconds is very
>> good.  Even though my example only have about 750,000 products, the
>> translations for the requested languages makes it into 750,000 * 6 =3D
>> 4,500,000 rows of product descriptions.  This is e-commerce site no=
t a
>> data warehouse/mining.  What would happen then if the site has over
>> 20,000,000 product skus with similar language translations for the
>> descriptions?  20,000,000 * 6 =3D ... big number to me...
>
> How exactly will threading in PHP help with the size of the database? Tha=
t makes no sense to me, please help me understand how you think threading w=
ill help in this scenario.

Looking at my example, not just the rows.... There are other features
that require queries to a DB for simple request of a category by a
shopper, instead of running those queries in series, running them in
parallel would yield better response time.


> Database size issues are tackled with clustering, caching and DB optimisa=
tion. Threading in the language accessing the DB has no advantage here.

Yes, it does. As mentioned several times, instead of running the
queries in series, run them in parallel. If each of the queries takes
about .05 to .15 seconds. How long would it take to run them in
serial? How long do you it take to run them in parallel?

>
> -Stuart
>
> --
> http://stut.net/

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

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

Per Jessen wrote:
> Rene Veerman wrote:
>
>> what you're suggesting is highly intrusive in my work-style, one that
>> you're not affected by at all.
>
> Hmm, you're the one suggesting a change, I'm suggesting no change. How
> can "no change" be intrusive?
>
>> in fact if you make things more difficult for me, i have less time to
>> release opensource code of my own.
>
> Well, we can't have that, so how about we stick to "no change", thereby
> not making anything more difficult for you. It will remain exactly as
> difficult as it is today.

That sounds very good to me! I'm STILL working through the warnings PHP5.3
introduced. It it improve anything. No ..... 5.2 still works just as well! Ican
well understand why people stayed with PHP4 for so long - but I never used that
myself.

Perhaps we need PHPforDummies and PHPforPros ... I'll stick with the Dummies
version, if I want the pro version I can go back to C++. ;)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

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

On 24 Mar 2010, at 10:34, Rene Veerman wrote:

> On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham =
wrote:
>>=20
>> 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....
>>=20
> Thanks for posting this before i had to.
>=20
> +1, +1, +1...

You realise, of course, that the same argument applies to using advanced =
features of PHP, such as threading should it ever be supported.

-Stuart

--=20
http://stut.net/=

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

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

--00151747691604af1504828990ae
Content-Type: text/plain; charset=ISO-8859-1

I subscribe to this list to share tips on software designs.

Getting and keeping your respect i'm not even interested in.

I'm interested in the quality of your tips on problems i post, as tips can
lead faster to products, leads to money, leads to my personal freedom and
options in life.
Respect cannot be used to buy bread and butter.




On Wed, Mar 24, 2010 at 11:55 AM, Ashley Sheridan
wrote:

> On Wed, 2010-03-24 at 11:56 +0200, Rene Veerman wrote:
>
> sad and pathetic? how about "revealing".
>
> i can call your sad and pathetic for:
> - insisting on how others should do their work.
> - group-attacking your opposition, hoping to intimidate by outnumbering.
> - ignoring all valid explanations on why someone would like their fav
> tool to evolve with the market.
> - degrading into petty insults as a way to indicate i'm probably right
> about the claim that led you to petty insults.
>
> i can go on, but i just dont want another political battle on my hands.
>
> i'll find out what the php dev team thinks about this issue, and base
> my descision on whether or not to leave php behind, on that.
>
> but you people truly are worthy of some serious IRL larting for being
> such assholes who think they can determine the habits of others that
> don't affect them.
> i dont usually do this, have never done it to programmers; but you're
> lucky we're not in the same buiding.
> i'd get you to try and punch me, followed by a relatively nonviolent
> yet very public humiliation.
> THATS how strongly i feel about those who determine the lifestyle of
> others when it doesn't even affect them.
>
> Seriously, wars have erupted over this behaviour. The kind where axes
> and such are used to settle the issue.
>
>
>
> Sorry Rene, but this has just made me lose all respect for you. I shan't be
> too sad if you do jump ship.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--00151747691604af1504828990ae--

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

--=-THg2p9Xq7giwjKtKjC9V
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-03-24 at 03:38 -0700, Tommy Pham wrote:

> On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote:
> > On 24 Mar 2010, at 10:24, Tommy Pham wrote:
> >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote:
> >>> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
> >>>
> >>>> unless the actual php development team would like to weigh in on this
> >>>> matter of course.
> >>>>
> >>>> yes, i do consider it that important.
> >>>>
> >>>> these nay-sayers usually also lobby the dev-team to such extent that
> >>>> these features would actually not make it into php.
> >>>
> >>> Frankly I don't give a crap whether threading is supported in PHP, it does everything I need it to do. If I need threading I use a language that supports it, like Python or C++.
> >>>
> >>> I love the way you call us nay-sayers like it's supposed to be an insult. I follow the KISS principle to the nth, and as such threading in PHP doesn't make a lot of sense to me. I'm yet to come across a problem I couldn't solve with pure PHP, but when the need arises I have no issue mixing in a little C++, Python, Ruby, or whatever, to meet my performance and scalability goals. I go to the mountain, I don't sit there complaining that the mountain ain't moving in my direction!
> >>>
> >>> My opinion, and that of most others who've weighed in, is that you're almost certainly looking at the problem from the wrong angle. What you haven't done is explicitly explain why you want threading to be supported. Give us a real example of why you think it should be supported and I guarantee we can come up with a way to get you what you want without requiring massive changes to the core of your chosen tool. And if we can't then you may actually convince us that threading would be a valuable feature to have available.
> >>
> >> I did give a real life example, ie e-commerce site mentioned earlier.
> >> Amazon has the similar features of my example except they have about
> >> 30 million products without (i18n). Their I18n is different web
> >> server & db & site layout which is completely different from my
> >> example. Setting I18n aside, having the same features as my example
> >> with about 30 million products to response in about 3 seconds is very
> >> good. Even though my example only have about 750,000 products, the
> >> translations for the requested languages makes it into 750,000 * 6 =
> >> 4,500,000 rows of product descriptions. This is e-commerce site not a
> >> data warehouse/mining. What would happen then if the site has over
> >> 20,000,000 product skus with similar language translations for the
> >> descriptions? 20,000,000 * 6 = ... big number to me...
> >
> > How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario.
>
> Looking at my example, not just the rows.... There are other features
> that require queries to a DB for simple request of a category by a
> shopper, instead of running those queries in series, running them in
> parallel would yield better response time.
>
>
> > Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here.
>
> Yes, it does. As mentioned several times, instead of running the
> queries in series, run them in parallel. If each of the queries takes
> about .05 to .15 seconds. How long would it take to run them in
> serial? How long do you it take to run them in parallel?
>
> >
> > -Stuart
> >
> > --
> > http://stut.net/
>


The database is still a bottleneck. Now instead of processing one query
at a time for a PHP script, it's processing 3 because you want them
processed in parallel. Now the database is struggling with 3 times the
work to complete in the same amount of time.

Threading hasn't helped that much here, you've just moved the problem to
an area which is already generally considered the bottleneck in most
applications.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-THg2p9Xq7giwjKtKjC9V--

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

Tommy Pham wrote:

> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas
> wrote:
>> Give us a real example of why you think it should be
>> supported and I guarantee we can come up with a way to get you what
>> you want without requiring massive changes to the core of your chose=
n
>> tool. And if we can't then you may actually convince us that
>> threading would be a valuable feature to have available.
>=20
> I did give a real life example, ie e-commerce site mentioned earlier.=


How many _concurrent_ users do you expect - which order of magnitude:
10,100,1000,10000?

> Amazon has the similar features of my example except they have about
> 30 million products without (i18n). Their I18n is different web
> server & db & site layout which is completely different from my
> example.=20

Understood.

> Setting I18n aside, having the same features as my example=20
> with about 30 million products to response in about 3 seconds is very=

> good. Even though my example only have about 750,000 products, the
> translations for the requested languages makes it into 750,000 * 6 =3D=

> 4,500,000 rows of product descriptions. This is e-commerce site not =
a
> data warehouse/mining. What would happen then if the site has over
> 20,000,000 product skus with similar language translations for the
> descriptions? 20,000,000 * 6 =3D ... big number to me...

Thinking out loud - maybe it would make sense to have a separate
database instance/machine per language? That would enable to you to
start them all on one machine, but shift to another once the load
increases. (not dynamically, but with time).
If that's not a feasible option, maybe a mysql cluster or a very large
database server? =20



--=20
Per Jessen, Zürich (12.2°C)


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

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

Tommy Pham wrote:

> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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.=20=

>>> 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 fac=
tors
>> to consider - developer productivity, available skills, future
>> maintenance, performance, scalability, portability, parallelism,
>> performance etcetera.
>>
>=20
> 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 PH=
P
> 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?=20
Tommy, that's a moot argument. You can't fit a square peg in a round
hole. =20



--=20
Per Jessen, Zürich (12.5°C)


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

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

On Wed, Mar 24, 2010 at 11:58 AM, Stuart Dallas wrote:
> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
>
>> unless the actual php development team would like to weigh in on this
>> matter of course.
>>
>> yes, i do consider it that important.
>>
>> these nay-sayers usually also lobby the dev-team to such extent that
>> these features would actually not make it into php.
>
> Frankly I don't give a crap whether threading is supported in PHP, it doe=
s everything I need it to do. If I need threading I use a language that sup=
ports it, like Python or C++.

good, so we'll put you down as a "neutral"... despite what follows;

>
> I love the way you call us nay-sayers like it's supposed to be an insult.=
I follow the KISS principle to the nth, and as such threading in PHP doesn=
't make a lot of sense to me. I'm yet to come across a problem I couldn't s=
olve with pure PHP, but when the need arises I have no issue mixing in a li=
ttle C++, Python, Ruby, or whatever, to meet my performance and scalability=
goals. I go to the mountain, I don't sit there complaining that the mounta=
in ain't moving in my direction!

your metaphor is funny but inaccurate. therefore invalid.

>
> My opinion, and that of most others who've weighed in, is that you're alm=
ost certainly looking at the problem from the wrong angle. What you haven't=
done is explicitly explain why you want threading to be supported. Give us=
a real example of why you think it should be supported and I guarantee we =
can come up with a way to get you what you want without requiring massive c=
hanges to the core of your chosen tool. And if we can't then you may actual=
ly convince us that threading would be a valuable feature to have available=
..


no sorry i don't have to. all i'll say is: realtime systems with real
work to do, are often better implemented with a non-sql solution that
can use threading and shared memory support. period.
it's so blatantly obvious that i don't feel like i have to spell out a
complete example, which YOU can then say: "ah, but there's different
ways of doing that!".
STOP TRYING TO DETERMINE MY HABITS AND CHOICE OF TOOLS.

> You mentioned Facebook as an example of a popular application. Are you aw=
are that they only recently started using their compiler in production, and=
that prior to that they were happily running PHP to serve their front end =
without ever complaining that it didn't support threading? Even now, with h=
ip-hop, individual requests are served in a single thread, so the language =
itself still doesn't support threading, and I don't hear them complaining t=
hat it's costing them a fortune. Why? Because it's not. And if it was they =
would have added it by now.


yea, they didn't complain, they had the cash income to build the
hip-hop compiler.
i thank 'm for it.

>
> One final thing... if threading is this important to you, then I'm sure t=
here are a number of developers who would happily add it in a fork of the c=
ore for suitable compensation. Once implemented it's possible the internals=
team would accept it for addition to the official version. If you really b=
elieve it has the potential to save you a butt-load of cash, the economics =
of paying for it should stack up.

I dont feel i need to pay for a programming language keeping up with the ti=
mes.
Then i'll indeed find another language to use.



>
>> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrot=
e:
>>> php is not a hammer, its a programming language.
>>>
>
> And bravo on the metaphor appreciation failure. Love it!
>
> -Stuart
>
> --
> http://stut.net/

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

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

On 24 Mar 2010, at 10:38, Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas =
wrote:
>> On 24 Mar 2010, at 10:24, Tommy Pham wrote:
>>> I did give a real life example, ie e-commerce site mentioned =
earlier.
>>> Amazon has the similar features of my example except they have about
>>> 30 million products without (i18n). Their I18n is different web
>>> server & db & site layout which is completely different from my
>>> example. Setting I18n aside, having the same features as my example
>>> with about 30 million products to response in about 3 seconds is =
very
>>> good. Even though my example only have about 750,000 products, the
>>> translations for the requested languages makes it into 750,000 * 6 =3D=

>>> 4,500,000 rows of product descriptions. This is e-commerce site not =
a
>>> data warehouse/mining. What would happen then if the site has over
>>> 20,000,000 product skus with similar language translations for the
>>> descriptions? 20,000,000 * 6 =3D ... big number to me...
>>=20
>> How exactly will threading in PHP help with the size of the database? =
That makes no sense to me, please help me understand how you think =
threading will help in this scenario.
>=20
> Looking at my example, not just the rows.... There are other features
> that require queries to a DB for simple request of a category by a
> shopper, instead of running those queries in series, running them in
> parallel would yield better response time.

I can see that argument, but your comment above only stated issues of =
database size, and said nothing about running queries in parallel, hence =
my confusion.

Threading would indeed allow you to run the queries in parallel, but at =
what cost? Personally I would focus on modifying the database structure =
and introducing caching to minimise the number of queries being =
executed. Threading would be my last resort if this was my major =
bottleneck.

-Stuart

--=20
http://stut.net/



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

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

On Wed, Mar 24, 2010 at 3:39 AM, Stuart Dallas wrote:
>
> On 24 Mar 2010, at 10:34, Rene Veerman wrote:
>
>> On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote:
>>>
>>> Funny you should mention all that.  Let's say that you're longer w=
ith
>>> that company, either by direct employment or contract consultant.
>>> You've implemented C because you need 'thread'.  Now your replacem=
ent
>>> comes in and has no clue about C even though your replacement is a PHP
>>> guru.  How much headache is maintenance gonna be?  Scalabilit=
y?
>>> Portability? wow....
>>>
>> Thanks for posting this before i had to.
>>
>> +1, +1, +1...
>
> You realise, of course, that the same argument applies to using advanced =
features of PHP, such as threading should it ever be supported.
>
> -Stuart
>

Thanks for supporting PHP thread. Thus, it would be a lot easier for
any PHP guru to scale, make it portable, or integrate into other PHP
apps without having to juggle C, Ruby, Python... and whatever else is
out there...

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

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

Tommy Pham wrote:
>> How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario.
>
> Looking at my example, not just the rows.... There are other features
> that require queries to a DB for simple request of a category by a
> shopper, instead of running those queries in series, running them in
> parallel would yield better response time.
>
>> Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here.
>
> Yes, it does. As mentioned several times, instead of running the
> queries in series, run them in parallel. If each of the queries takes
> about .05 to .15 seconds. How long would it take to run them in
> serial? How long do you it take to run them in parallel?

Any you have a database that can actually handle that?
If the database is taking 0.1 seconds per query, and you have 10 queries, then
getting the data is going to take 1 second to generate. If you want some slow
query to be started, and come back for the data later, then I thought we already
had that? But again this is part of the database driver anyway. No need to add
threading to PHP to get the database connection to pull data in the most
efficient way. And one does not write the driver in PHP? We are using C there
already?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

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

On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote:
> Tommy Pham wrote:
>
>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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 factor=
s
>>> 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 wi=
th
>> that company, either by direct employment or contract consultant.
>> You've implemented C because you need 'thread'.  Now your replaceme=
nt
>> 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 roun=
d
> 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....

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

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

On Wed, Mar 24, 2010 at 3:40 AM, Ashley Sheridan
wrote:
>
> On Wed, 2010-03-24 at 03:38 -0700, Tommy Pham wrote:
>
> On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote:
> > On 24 Mar 2010, at 10:24, Tommy Pham wrote:
> >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wro=
te:
> >>> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
> >>>
> >>>> unless the actual php development team would like to weigh in on thi=
s
> >>>> matter of course.
> >>>>
> >>>> yes, i do consider it that important.
> >>>>
> >>>> these nay-sayers usually also lobby the dev-team to such extent that
> >>>> these features would actually not make it into php.
> >>>
> >>> Frankly I don't give a crap whether threading is supported in PHP, it=
does everything I need it to do. If I need threading I use a language that=
supports it, like Python or C++.
> >>>
> >>> I love the way you call us nay-sayers like it's supposed to be an ins=
ult. I follow the KISS principle to the nth, and as such threading in PHP d=
oesn't make a lot of sense to me. I'm yet to come across a problem I couldn=
't solve with pure PHP, but when the need arises I have no issue mixing in =
a little C++, Python, Ruby, or whatever, to meet my performance and scalabi=
lity goals. I go to the mountain, I don't sit there complaining that the mo=
untain ain't moving in my direction!
> >>>
> >>> My opinion, and that of most others who've weighed in, is that you're=
almost certainly looking at the problem from the wrong angle. What you hav=
en't done is explicitly explain why you want threading to be supported. Giv=
e us a real example of why you think it should be supported and I guarantee=
we can come up with a way to get you what you want without requiring massi=
ve changes to the core of your chosen tool. And if we can't then you may ac=
tually convince us that threading would be a valuable feature to have avail=
able.
> >>
> >> I did give a real life example, ie e-commerce site mentioned earlier.
> >> Amazon has the similar features of my example except they have about
> >> 30 million products without (i18n).  Their I18n is different web
> >> server & db & site layout which is completely different from my
> >> example.  Setting I18n aside, having the same features as my exam=
ple
> >> with about 30 million products to response in about 3 seconds is very
> >> good.  Even though my example only have about 750,000 products, t=
he
> >> translations for the requested languages makes it into 750,000 * 6 =3D
> >> 4,500,000 rows of product descriptions.  This is e-commerce site =
not a
> >> data warehouse/mining.  What would happen then if the site has ov=
er
> >> 20,000,000 product skus with similar language translations for the
> >> descriptions?  20,000,000 * 6 =3D ... big number to me...
> >
> > How exactly will threading in PHP help with the size of the database? T=
hat makes no sense to me, please help me understand how you think threading=
will help in this scenario.
>
> Looking at my example, not just the rows.... There are other features
> that require queries to a DB for simple request of a category by a
> shopper, instead of running those queries in series, running them in
> parallel would yield better response time.
>
>
> > Database size issues are tackled with clustering, caching and DB optimi=
sation. Threading in the language accessing the DB has no advantage here.
>
> Yes, it does. As mentioned several times, instead of running the
> queries in series, run them in parallel. If each of the queries takes
> about .05 to .15 seconds. How long would it take to run them in
> serial? How long do you it take to run them in parallel?
>
> >
> > -Stuart
> >
> > --
> > http://stut.net/
>
>
> The database is still a bottleneck. Now instead of processing one query a=
t a time for a PHP script, it's processing 3 because you want them processe=
d in parallel. Now the database is struggling with 3 times the work to comp=
lete in the same amount of time.
>
> Threading hasn't helped that much here, you've just moved the problem to =
an area which is already generally considered the bottleneck in most applic=
ations.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>

Take your current project. Look at the page where the most queries
are executed. Time how long it would take to run each of those
queries in your SQL GUI Tool. Add the numbers together. Now think
how long it would take to run those same queries under the same
conditions in parallel. ... :)

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

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

On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote:
> Tommy Pham wrote:
>>>
>>> How exactly will threading in PHP help with the size of the database?
>>> That makes no sense to me, please help me understand how you think thre=
ading
>>> will help in this scenario.
>>
>> Looking at my example, not just the rows....  There are other featu=
res
>> that require queries to a DB for simple request of a category by a
>> shopper,  instead of running those queries in series, running them =
in
>> parallel would yield better response time.
>>
>>> Database size issues are tackled with clustering, caching and DB
>>> optimisation. Threading in the language accessing the DB has no advanta=
ge
>>> here.
>>
>> Yes, it does.  As mentioned several times, instead of running the
>> queries in series, run them in parallel.  If each of the queries ta=
kes
>> about .05 to .15 seconds.  How long would it take to run them in
>> serial?  How long do you it take to run them in parallel?
>
> Any you have a database that can actually handle that?
> If the database is taking 0.1 seconds per query, and you have 10 queries,
> then getting the data is going to take 1 second to generate. If you want
> some slow query to be started, and come back for the data later, then I
> thought we already had that? But again this is part of the database drive=
r
> anyway. No need to add threading to PHP to get the database connection to
> pull data in the most efficient way. And one does not write the driver in
> PHP? We are using C there already?
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Exactly my point. 10 queries taking .1 second each running in serial
is 1 second total. How long would it take to run all those same
queries simultaneously??? What's so difficult about the concept of
serial vs parallel?

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

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

On 24 March 2010 11:53, Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote:
>> Tommy Pham wrote:
>>
>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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 facto=
rs
>>>> 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 w=
ith
>>> that company, either by direct employment or contract consultant.
>>> You've implemented C because you need 'thread'.  Now your replacem=
ent
>>> comes in and has no clue about C even though your replacement is a PHP
>>> guru.  How much headache is maintenance gonna be?  Scalabilit=
y?
>>> 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 rou=
nd
>> 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....

Except, you already introduced complexity into the problem. You see,
working with threads is another requirement, whether it be done in PHP
or not. Hence, hiring the right guy is independent of whether you have
threads in PHP or not - your problem is no less nor no more complex
whether you do threading inside or outside PHP. You just assume that
adding thread support to PHP will solve the problem, but there's no
actual basis to believe this.


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



--=20

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51


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

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

On 24 March 2010 12:04, Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote:
>> Tommy Pham wrote:
>>>>
>>>> How exactly will threading in PHP help with the size of the database?
>>>> That makes no sense to me, please help me understand how you think thr=
eading
>>>> will help in this scenario.
>>>
>>> Looking at my example, not just the rows....  There are other feat=
ures
>>> that require queries to a DB for simple request of a category by a
>>> shopper,  instead of running those queries in series, running them=
in
>>> parallel would yield better response time.
>>>
>>>> Database size issues are tackled with clustering, caching and DB
>>>> optimisation. Threading in the language accessing the DB has no advant=
age
>>>> here.
>>>
>>> Yes, it does.  As mentioned several times, instead of running the
>>> queries in series, run them in parallel.  If each of the queries t=
akes
>>> about .05 to .15 seconds.  How long would it take to run them in
>>> serial?  How long do you it take to run them in parallel?
>>
>> Any you have a database that can actually handle that?
>> If the database is taking 0.1 seconds per query, and you have 10 queries=
,
>> then getting the data is going to take 1 second to generate. If you want
>> some slow query to be started, and come back for the data later, then I
>> thought we already had that? But again this is part of the database driv=
er
>> anyway. No need to add threading to PHP to get the database connection t=
o
>> pull data in the most efficient way. And one does not write the driver i=
n
>> PHP? We are using C there already?
>>
>> --
>> Lester Caine - G8HFL
>> -----------------------------
>> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
>> L.S.Caine Electronic Services - http://lsces.co.uk
>> EnquirySolve - http://enquirysolve.com/
>> Model Engineers Digital Workshop - http://medw.co.uk//
>> Firebird - http://www.firebirdsql.org/index.php
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> Exactly my point.  10 queries taking .1 second each running in seria=
l
> is 1 second total.  How long would it take to run all those same
> queries simultaneously??? What's so difficult about the concept of
> serial vs parallel?

Hmm, just wondering, but how long do you think it will take your
high-traffic site to buckle under the load of the database queries you
want to execute when now you want all of them to execute at the same
time? Going with the "10 queries of .1 second each" ... how far do you
think you can scale that before you overload your database server? I'm
just wondering here, I could be completely off the bat.

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



--=20

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51


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

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

yea right..

i really want to keep my code base in 1 language, because that
simplifies everything later on imo.
you people, who are against the evolotion of php towards cloud
computing, would force me to do mixed-languages projects or even
rewrite large sections of my codebase if as i want, i keep my codebase
in 1 language.

maybe now you understand why i'm so pissed off with you know-it-alls.


On Wed, Mar 24, 2010 at 1:04 PM, Peter Lind wrote:
> On 24 March 2010 11:53, Tommy Pham wrote:
>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote:
>>> Tommy Pham wrote:
>>>
>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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. =A0When 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. =A0Let's say that you're longer wit=
h
>>>> that company, either by direct employment or contract consultant.
>>>> You've implemented C because you need 'thread'. =A0Now your replacemen=
t
>>>> comes in and has no clue about C even though your replacement is a PHP
>>>> guru. =A0How much headache is maintenance gonna be? =A0Scalability?
>>>> Portability? wow....
>>>
>>> Who was the idi... who hired someone who wasn't suited for the job?
>>> Tommy, that's a moot argument. =A0You can't fit a square peg in a round
>>> hole.
>>>
>>>
>>>
>>> --
>>> Per Jessen, Zürich (12.5°C)
>>>
>>>
>>
>> Suited for the job? =A0You mean introduce more complexity to a problem
>> that what could be avoided to begin with if PHP has thread support?
>> hmmm....
>
> Except, you already introduced complexity into the problem. You see,
> working with threads is another requirement, whether it be done in PHP
> or not. Hence, hiring the right guy is independent of whether you have
> threads in PHP or not - your problem is no less nor no more complex
> whether you do threading inside or outside PHP. You just assume that
> adding thread support to PHP will solve the problem, but there's no
> actual basis to believe this.
>
>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> Flickr: http://www.flickr.com/photos/fake51
> BeWelcome: Fake51
> Couchsurfing: Fake51
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

On 24 Mar 2010, at 10:46, Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 11:58 AM, Stuart Dallas =
wrote:
>> On 24 Mar 2010, at 09:36, Rene Veerman wrote:
>>=20
>>> unless the actual php development team would like to weigh in on =
this
>>> matter of course.
>>>=20
>>> yes, i do consider it that important.
>>>=20
>>> these nay-sayers usually also lobby the dev-team to such extent that
>>> these features would actually not make it into php.
>>=20
>> Frankly I don't give a crap whether threading is supported in PHP, it =
does everything I need it to do. If I need threading I use a language =
that supports it, like Python or C++.
>=20
> good, so we'll put you down as a "neutral"... despite what follows;

I'm not neutral, I just ultimately don't care either way. I'll deal with =
whatever happens rather than trying to control everything.

>> I love the way you call us nay-sayers like it's supposed to be an =
insult. I follow the KISS principle to the nth, and as such threading in =
PHP doesn't make a lot of sense to me. I'm yet to come across a problem =
I couldn't solve with pure PHP, but when the need arises I have no issue =
mixing in a little C++, Python, Ruby, or whatever, to meet my =
performance and scalability goals. I go to the mountain, I don't sit =
there complaining that the mountain ain't moving in my direction!
>=20
> your metaphor is funny but inaccurate. therefore invalid.

You say it's inaccurate, therefore invalid, but offer no argument as to =
why. You want the tools to change to fit the way you want to work, =
rather than adapting to the tools you have available. I stand by my =
metaphor, both the humour and the message.

>> My opinion, and that of most others who've weighed in, is that you're =
almost certainly looking at the problem from the wrong angle. What you =
haven't done is explicitly explain why you want threading to be =
supported. Give us a real example of why you think it should be =
supported and I guarantee we can come up with a way to get you what you =
want without requiring massive changes to the core of your chosen tool. =
And if we can't then you may actually convince us that threading would =
be a valuable feature to have available.
>=20
>=20
> no sorry i don't have to. all i'll say is: realtime systems with real

Indeed you don't have to, I never said you did.

> work to do, are often better implemented with a non-sql solution that
> can use threading and shared memory support. period.

I completely agree, but I wouldn't go near PHP for a realtime system in =
a million years. It's the wrong tool for the job.

> it's so blatantly obvious that i don't feel like i have to spell out a
> complete example, which YOU can then say: "ah, but there's different
> ways of doing that!".
> STOP TRYING TO DETERMINE MY HABITS AND CHOICE OF TOOLS.

I'm not. You seem to think we all care whether you use PHP or not. I =
don't, and I'm pretty sure nobody else does either. I'm not trying to =
tell you what to use, I'm simply pointing out that you appear to be =
fixed on PHP for some reason and I don't understand why. It makes no =
sense to me, but frankly I don't care.

>> You mentioned Facebook as an example of a popular application. Are =
you aware that they only recently started using their compiler in =
production, and that prior to that they were happily running PHP to =
serve their front end without ever complaining that it didn't support =
threading? Even now, with hip-hop, individual requests are served in a =
single thread, so the language itself still doesn't support threading, =
and I don't hear them complaining that it's costing them a fortune. Why? =
Because it's not. And if it was they would have added it by now.
>=20
> yea, they didn't complain, they had the cash income to build the
> hip-hop compiler.
> i thank 'm for it.

Way to skip over my point. Facebook is pretty much guaranteed to be a =
bigger site in terms of data size and concurrent users than anything you =
or I are ever going to be involved in, and yet they don't think =
threading in PHP is important. That was my point.

>> One final thing... if threading is this important to you, then I'm =
sure there are a number of developers who would happily add it in a fork =
of the core for suitable compensation. Once implemented it's possible =
the internals team would accept it for addition to the official version. =
If you really believe it has the potential to save you a butt-load of =
cash, the economics of paying for it should stack up.
>=20
> I dont feel i need to pay for a programming language keeping up with =
the times.
> Then i'll indeed find another language to use.

I find it curious and amusing that you think the lack of threading =
support means PHP is somehow living in the dark ages. But yeah, =
complaining that the FREE tool you've CHOSEN to use doesn't support the =
feature YOU want... yeah, that's the way to go.

-Stuart

--=20
http://stut.net/


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

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

On Wed, Mar 24, 2010 at 4:09 AM, Peter Lind wrote:
> On 24 March 2010 12:04, Tommy Pham wrote:
>> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote=
:
>>> Tommy Pham wrote:
>>>>>
>>>>> How exactly will threading in PHP help with the size of the database?
>>>>> That makes no sense to me, please help me understand how you think th=
reading
>>>>> will help in this scenario.
>>>>
>>>> Looking at my example, not just the rows....  There are other fea=
tures
>>>> that require queries to a DB for simple request of a category by a
>>>> shopper,  instead of running those queries in series, running the=
m in
>>>> parallel would yield better response time.
>>>>
>>>>> Database size issues are tackled with clustering, caching and DB
>>>>> optimisation. Threading in the language accessing the DB has no advan=
tage
>>>>> here.
>>>>
>>>> Yes, it does.  As mentioned several times, instead of running the
>>>> queries in series, run them in parallel.  If each of the queries =
takes
>>>> about .05 to .15 seconds.  How long would it take to run them in
>>>> serial?  How long do you it take to run them in parallel?
>>>
>>> Any you have a database that can actually handle that?
>>> If the database is taking 0.1 seconds per query, and you have 10 querie=
s,
>>> then getting the data is going to take 1 second to generate. If you wan=
t
>>> some slow query to be started, and come back for the data later, then I
>>> thought we already had that? But again this is part of the database dri=
ver
>>> anyway. No need to add threading to PHP to get the database connection =
to
>>> pull data in the most efficient way. And one does not write the driver =
in
>>> PHP? We are using C there already?
>>>
>>> --
>>> Lester Caine - G8HFL
>>> -----------------------------
>>> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
>>> L.S.Caine Electronic Services - http://lsces.co.uk
>>> EnquirySolve - http://enquirysolve.com/
>>> Model Engineers Digital Workshop - http://medw.co.uk//
>>> Firebird - http://www.firebirdsql.org/index.php
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> Exactly my point.  10 queries taking .1 second each running in seri=
al
>> is 1 second total.  How long would it take to run all those same
>> queries simultaneously??? What's so difficult about the concept of
>> serial vs parallel?
>
> Hmm, just wondering, but how long do you think it will take your
> high-traffic site to buckle under the load of the database queries you
> want to execute when now you want all of them to execute at the same
> time? Going with the "10 queries of .1 second each" ... how far do you
> think you can scale that before you overload your database server? I'm
> just wondering here, I could be completely off the bat.

IIRC, one of opponents of PHP thread mention load balancer/cluster or
another opponent mention 'throw money into the hardware problem'

>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> Flickr: http://www.flickr.com/photos/fake51
> BeWelcome: Fake51
> Couchsurfing: Fake51
>
>

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

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

On 24 Mar 2010, at 10:48, Tommy Pham wrote:

> On Wed, Mar 24, 2010 at 3:39 AM, Stuart Dallas =
wrote:
>>=20
>> On 24 Mar 2010, at 10:34, Rene Veerman wrote:
>>=20
>>> On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham =
wrote:
>>>>=20
>>>> 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....
>>>>=20
>>> Thanks for posting this before i had to.
>>>=20
>>> +1, +1, +1...
>>=20
>> You realise, of course, that the same argument applies to using =
advanced features of PHP, such as threading should it ever be supported.
>>=20
>> -Stuart
>>=20
>=20
> Thanks for supporting PHP thread. Thus, it would be a lot easier for
> any PHP guru to scale, make it portable, or integrate into other PHP
> apps without having to juggle C, Ruby, Python... and whatever else is
> out there...

I don't believe I did support PHP threading. My point was that using =
advanced features like threading will limit your employee choices in =
exactly the same way as having a multi-language environment.

-Stuart

--=20
http://stut.net/


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

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

Stuart Dallas wrote:

>>> I love the way you call us nay-sayers like it's supposed to be an
>>> insult. I follow the KISS principle to the nth, and as such
>>> threading in PHP doesn't make a lot of sense to me. I'm yet to come=

>>> across a problem I couldn't solve with pure PHP, but when the need
>>> arises I have no issue mixing in a little C++, Python, Ruby, or
>>> whatever, to meet my performance and scalability goals. I go to the=

>>> mountain, I don't sit there complaining that the mountain ain't
>>> moving in my direction!
>>=20
>> your metaphor is funny but inaccurate. therefore invalid.
>=20
> You say it's inaccurate, therefore invalid, but offer no argument as
> to why. You want the tools to change to fit the way you want to work,=

> rather than adapting to the tools you have available. I stand by my
> metaphor, both the humour and the message.

FWIW, I thought your metaphor was spot on. Programming is a craft,
craftsmen use tools, whether hammers or PHP.

>> work to do, are often better implemented with a non-sql solution tha=
t
>> can use threading and shared memory support. period.
>=20
> I completely agree, but I wouldn't go near PHP for a realtime system
> in a million years. It's the wrong tool for the job.

+1.=20



--=20
Per Jessen, Zürich (13.2°C)


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

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

Peter Lind wrote:
>>> Any you have a database that can actually handle that?
>>> If the database is taking 0.1 seconds per query, and you have 10 queries,
>>> then getting the data is going to take 1 second to generate. If you want
>>> some slow query to be started, and come back for the data later, then I
>>> thought we already had that? But again this is part of the database driver
>>> anyway. No need to add threading to PHP to get the database connection to
>>> pull data in the most efficient way. And one does not write the driver in
>>> PHP? We are using C there already?

>> Exactly my point. 10 queries taking .1 second each running in serial
>> is 1 second total. How long would it take to run all those same
>> queries simultaneously??? What's so difficult about the concept of
>> serial vs parallel?
>
> Hmm, just wondering, but how long do you think it will take your
> high-traffic site to buckle under the load of the database queries you
> want to execute when now you want all of them to execute at the same
> time? Going with the "10 queries of .1 second each" ... how far do you
> think you can scale that before you overload your database server? I'm
> just wondering here, I could be completely off the bat.

No you are not off bat. That was the point I was trying to make but not very
well. A database connection will normally handle one query at a time, so they
have to be serial anyway unles you can create multiple connections. What I was
asking Tommy was how he expected the database to handle 10 queries in parallel.
Yes ten cores could possibly parallel up the work, but on the whole, the
database end is going to serialise a lot of that work, so what is the real gain?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

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

On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas
> I find it curious and amusing that you think the lack of threading support means PHP is somehow living in the dark ages. But yeah, complaining that the FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, that's the way to go.
>

a) i'm not the only 1 who wants that feature, or would appreciate it
when it's made available.

b) to me it's a matter of keeping php attuned with the market trends.
this thread forces me to reconsider my choice of language, because i
do code to maybe get as big as facebook one day.
it really really helps to have my codebase in a simple language like
php, and yet be able to build blackboxes in that language that do
threading and use shared memory..
imo, it saves significant time (money) and headaches (risk) when
growing from 1 server to thousands of servers.

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

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

Tommy Pham wrote:

> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote:=

>> Tommy Pham wrote:
>>
>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen
>>> 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 f=
actors
>>>> 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 long=
er
>>> with that company, either by direct employment or contract
>>> consultant. You've implemented C because you need 'thread'.  N=
ow
>>> your replacement comes in and has no clue about C even though your
>>> replacement is a PHP guru.  How much headache is maintenance g=
onna
>>> 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)
>>
>=20
> 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.=20


--=20
Per Jessen, Zürich (13.4°C)


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

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

how about having a threaded php server query 10 mysql servers at the
same time? 10 results in .1 seconds!

and dont start with 'apache will handle that', there are cases where
you're best off doing it in php, so you can gather/calculate relations
from the data off 10 different servers.

On Wed, Mar 24, 2010 at 1:09 PM, Peter Lind wrote:
> On 24 March 2010 12:04, Tommy Pham wrote:
>> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote=
:
>>> Tommy Pham wrote:
>>>>>
>>>>> How exactly will threading in PHP help with the size of the database?
>>>>> That makes no sense to me, please help me understand how you think th=
reading
>>>>> will help in this scenario.
>>>>
>>>> Looking at my example, not just the rows.... =A0There are other featur=
es
>>>> that require queries to a DB for simple request of a category by a
>>>> shopper, =A0instead of running those queries in series, running them i=
n
>>>> parallel would yield better response time.
>>>>
>>>>> Database size issues are tackled with clustering, caching and DB
>>>>> optimisation. Threading in the language accessing the DB has no advan=
tage
>>>>> here.
>>>>
>>>> Yes, it does. =A0As mentioned several times, instead of running the
>>>> queries in series, run them in parallel. =A0If each of the queries tak=
es
>>>> about .05 to .15 seconds. =A0How long would it take to run them in
>>>> serial? =A0How long do you it take to run them in parallel?
>>>
>>> Any you have a database that can actually handle that?
>>> If the database is taking 0.1 seconds per query, and you have 10 querie=
s,
>>> then getting the data is going to take 1 second to generate. If you wan=
t
>>> some slow query to be started, and come back for the data later, then I
>>> thought we already had that? But again this is part of the database dri=
ver
>>> anyway. No need to add threading to PHP to get the database connection =
to
>>> pull data in the most efficient way. And one does not write the driver =
in
>>> PHP? We are using C there already?
>>>
>>> --
>>> Lester Caine - G8HFL
>>> -----------------------------
>>> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
>>> L.S.Caine Electronic Services - http://lsces.co.uk
>>> EnquirySolve - http://enquirysolve.com/
>>> Model Engineers Digital Workshop - http://medw.co.uk//
>>> Firebird - http://www.firebirdsql.org/index.php
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> Exactly my point. =A010 queries taking .1 second each running in serial
>> is 1 second total. =A0How long would it take to run all those same
>> queries simultaneously??? What's so difficult about the concept of
>> serial vs parallel?
>
> Hmm, just wondering, but how long do you think it will take your
> high-traffic site to buckle under the load of the database queries you
> want to execute when now you want all of them to execute at the same
> time? Going with the "10 queries of .1 second each" ... how far do you
> think you can scale that before you overload your database server? I'm
> just wondering here, I could be completely off the bat.
>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> Flickr: http://www.flickr.com/photos/fake51
> BeWelcome: Fake51
> Couchsurfing: Fake51
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

Rene Veerman wrote:

> i really want to keep my code base in 1 language, because that
> simplifies everything later on imo.

Yes, generally speaking that's a good idea. Not always the optimal
choice when you weigh up the requirements and the available skillsets,
but nonetheless.=20



--=20
Per Jessen, Zürich (13.4°C)


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

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

Rene Veerman wrote:

> b) to me it's a matter of keeping php attuned with the market trends.=

> this thread forces me to reconsider my choice of language, because i
> do code to maybe get as big as facebook one day.

Nothing wrong with that, nothing at all. The keyword is scalability,
and that is measured by how much performance you gain by adding another=

box. You appear to be far more concerned with how much you can get out=

of a single, small box, and that's the wrong focus, IMHO.=20



--=20
Per Jessen, Zürich (13.7°C)


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

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

On Wed, Mar 24, 2010 at 12:27, Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas
>> I find it curious and amusing that you think the lack of threading support means PHP is somehow living in the dark ages. But yeah, complaining that the FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, that's the way to go.
>>
>
> a) i'm not the only 1 who wants that feature, or would appreciate it
> when it's made available.
>
> b) to me it's a matter of keeping php attuned with the market trends.
> this thread forces me to reconsider my choice of language, because i
> do code to maybe get as big as facebook one day.
> it really really helps to have my codebase in a simple language like
> php, and yet be able to build blackboxes in that language that do
> threading and use shared memory..
> imo, it saves significant time (money) and headaches (risk) when
> growing from 1 server to thousands of servers.

If you believe you have the chance of becoming as big as Facebook and
that you would save loads of money by having PHP support
multi-threading, what's preventing you from hiring people to add that
to PHP? You can complain all you want, but even with the most
compelling reasons in the world it will not be done if there is not
enough manpower to do it.

I'm not even sure why you are complaining about this on the general
list. Why don't you write an RFC and send it to internals for
discussion? I'm sure someone would be happy to give you write access
to the rfc namespace on the wiki if you sign up for an account there.

Seeing as it's apparently so crucial to the operation of your
business, I don't think it's unreasonable that you commit some
resources to it. I don't think anyone is *against* that PHP supports
multi-threading. I think people are against having multi-threading if
it will stall other development in the PHP core. It's not like you can
implement it just like that. There is just a limit on how much that
can be done with the resources that are available.

--
Daniel Egeberg

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

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

well i have this very strong gut feeling that at least some php apps
stand to gain so much efficiency per box with threading and shared
memory that they'll save not only their operators a lot of headaches,
but also significant money and energy. that in turn benefits those
outside the company using php.

On Wed, Mar 24, 2010 at 1:42 PM, Per Jessen wrote:
> Rene Veerman wrote:
>
>> b) to me it's a matter of keeping php attuned with the market trends.
>> this thread forces me to reconsider my choice of language, because i
>> do code to maybe get as big as facebook one day.
>
> Nothing wrong with that, nothing at all. =A0The keyword is scalability,
> and that is measured by how much performance you gain by adding another
> box. =A0You appear to be far more concerned with how much you can get out
> of a single, small box, and that's the wrong focus, IMHO.
>
>

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

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

Rene Veerman wrote:

> how about having a threaded php server query 10 mysql servers at the
> same time? 10 results in .1 seconds!
>=20

How about using mysqlnd? AFAIK, it has support for asynchronous
queries.=20


--=20
Per Jessen, Zürich (14.2°C)


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

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

again; i have neither the expertise ready, nor the time nor the money
atm, to implement it myself.

i'm hoping the php-dev team will agree with me that scalability of php
driven apps should be put on the agenda.

threading and shared memory are only a part of that discussion..
i'm opening a new thread to discuss this wider issue.


On Wed, Mar 24, 2010 at 1:44 PM, Daniel Egeberg wrote:
> On Wed, Mar 24, 2010 at 12:27, Rene Veerman wrote:
>> On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas
>>> I find it curious and amusing that you think the lack of threading support means PHP is somehow living in the dark ages. But yeah, complaining that the FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, that's the way to go.
>>>
>>
>> a) i'm not the only 1 who wants that feature, or would appreciate it
>> when it's made available.
>>
>> b) to me it's a matter of keeping php attuned with the market trends.
>> this thread forces me to reconsider my choice of language, because i
>> do code to maybe get as big as facebook one day.
>> it really really helps to have my codebase in a simple language like
>> php, and yet be able to build blackboxes in that language that do
>> threading and use shared memory..
>> imo, it saves significant time (money) and headaches (risk) when
>> growing from 1 server to thousands of servers.
>
> If you believe you have the chance of becoming as big as Facebook and
> that you would save loads of money by having PHP support
> multi-threading, what's preventing you from hiring people to add that
> to PHP? You can complain all you want, but even with the most
> compelling reasons in the world it will not be done if there is not
> enough manpower to do it.
>
> I'm not even sure why you are complaining about this on the general
> list. Why don't you write an RFC and send it to internals for
> discussion? I'm sure someone would be happy to give you write access
> to the rfc namespace on the wiki if you sign up for an account there.
>
> Seeing as it's apparently so crucial to the operation of your
> business, I don't think it's unreasonable that you commit some
> resources to it. I don't think anyone is *against* that PHP supports
> multi-threading. I think people are against having multi-threading if
> it will stall other development in the PHP core. It's not like you can
> implement it just like that. There is just a limit on how much that
> can be done with the resources that are available.
>
> --
> Daniel Egeberg
>

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

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

On 24 March 2010 12:14, Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 4:09 AM, Peter Lind wrot=
e:
>> On 24 March 2010 12:04, Tommy Pham wrote:
>>> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrot=
e:
>>>> Tommy Pham wrote:
>>>>>>
>>>>>> How exactly will threading in PHP help with the size of the database=
?
>>>>>> That makes no sense to me, please help me understand how you think t=
hreading
>>>>>> will help in this scenario.
>>>>>
>>>>> Looking at my example, not just the rows....  There are other fe=
atures
>>>>> that require queries to a DB for simple request of a category by a
>>>>> shopper,  instead of running those queries in series, running th=
em in
>>>>> parallel would yield better response time.
>>>>>
>>>>>> Database size issues are tackled with clustering, caching and DB
>>>>>> optimisation. Threading in the language accessing the DB has no adva=
ntage
>>>>>> here.
>>>>>
>>>>> Yes, it does.  As mentioned several times, instead of running th=
e
>>>>> queries in series, run them in parallel.  If each of the queries=
takes
>>>>> about .05 to .15 seconds.  How long would it take to run them in
>>>>> serial?  How long do you it take to run them in parallel?
>>>>
>>>> Any you have a database that can actually handle that?
>>>> If the database is taking 0.1 seconds per query, and you have 10 queri=
es,
>>>> then getting the data is going to take 1 second to generate. If you wa=
nt
>>>> some slow query to be started, and come back for the data later, then =
I
>>>> thought we already had that? But again this is part of the database dr=
iver
>>>> anyway. No need to add threading to PHP to get the database connection=
to
>>>> pull data in the most efficient way. And one does not write the driver=
in
>>>> PHP? We are using C there already?
>>>>
>>>> --
>>>> Lester Caine - G8HFL
>>>> -----------------------------
>>>> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
>>>> L.S.Caine Electronic Services - http://lsces.co.uk
>>>> EnquirySolve - http://enquirysolve.com/
>>>> Model Engineers Digital Workshop - http://medw.co.uk//
>>>> Firebird - http://www.firebirdsql.org/index.php
>>>>
>>>> --
>>>> PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>>>
>>> Exactly my point.  10 queries taking .1 second each running in ser=
ial
>>> is 1 second total.  How long would it take to run all those same
>>> queries simultaneously??? What's so difficult about the concept of
>>> serial vs parallel?
>>
>> Hmm, just wondering, but how long do you think it will take your
>> high-traffic site to buckle under the load of the database queries you
>> want to execute when now you want all of them to execute at the same
>> time? Going with the "10 queries of .1 second each" ... how far do you
>> think you can scale that before you overload your database server? I'm
>> just wondering here, I could be completely off the bat.
>
> IIRC, one of opponents of PHP thread mention load balancer/cluster or
> another opponent mention 'throw money into the hardware problem'

Yes. If you can accept that solution for this problem, why not for the
other problem?

Please keep in mind that I'm not for or against threads in PHP. I
think they can solve some problems and I think they'll create a host
of others - currently I have no idea if the benefits would outweigh
the costs.

I just have a huge problem understanding why alternative solutions to
problems are thrown out with "No! That won't work" when they haven't
been shown to be problematic. So far, we've seen no examples of
situations where PHP would be the best choice of language and would
need threads to solve the problem at hand.

Assuming that you have a right to use a threaded version of PHP
amounts to walking into your favourite tool-store and demanding that
you get a hammer that doubles as a phone. And when none are available,
you start yelling at other customers for suggesting the use of a phone
and hammer in combination.

>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>>
>>
>> --
>>
>> WWW: http://plphp.dk / http://plind.dk
>> LinkedIn: http://www.linkedin.com/in/plind
>> Flickr: http://www.flickr.com/photos/fake51
>> BeWelcome: Fake51
>> Couchsurfing: Fake51
>>
>>
>



--=20

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51


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

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

Per Jessen wrote:
> Rene Veerman wrote:
>
>> stop bashing the people who DO have a use for threading and other
>> advanced concepts eh.
>
> I'm not bashing anyone.
>
>> just because you don't have a use for it, it shouldn't be included?!
>> kinda arrogant.
>
> Feel free to think so - I never said I don't have a use for it
> (threading), I just said thread-support doesn't belong in PHP.

This is a more interesting statement since this thread started with
"douche-bag". I disagree with your assertion that it doesn't belong in
PHP, I think threading has its merits, but the kinds of problems thrown
at this thread so far don't seem particularly solved by threading. 500
requests each with 10 threads hitting the database is 5000 queries.
Threading isn't going to make a whole hell of a lot of difference versus
10 serial queries sent by the same 500 web server requests-- multi core
system or otherwise. Facebook and other popular sites get along well
with PHP. Note that Facebook created a compiler for PHP, they didn't add
support for threading. This suggests that threading is not the golden
hammer being sought in this thread.

However, threading certainly would be great for doing more desktoppy
stuff :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> popular : facebook youtube etc

I doubt very much you're popular like facebook. Nothing is as popular as
facebook.

http://www.fastcompany.com/1584920/facebook-now-more-popular -than-google-let-the-ad-wars-begin

Unless you're actually a facebook developer... which I doubt.

> and you're still trying to impose a toolset on me. i think it's not
> strange to ask a programming language support basic hardware
> architecture features as they evolve into mainstream.

No, you've imposed the toolset and now you want to change the set.
Nothing wrong with wanting a new tool in your bag, but you're current
arguments aren't really passing muster.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> talk to me about this some other time.
>
> atm i'm having an argument with per and his kind about their very very
> annoying behaviour of determining my toolset for me.
> keeping a thread on topic is also ettiquette from the mailinglist rules eh?
>
> you might wanna consider just how much it pisses me off to have strangers
> determining my toolset and/or lifestyle for me.
> that's why i got rude. no other reason.

Umm... you or your boss/client chose PHP. That means one of those two
determined your toolset. Maybe next time you might want to pony up for a
requirements analysis to determine if the toolset is right for the job.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 10:36 AM, Per Jessen wrote:
>
>> By advocating that thread support does not belong in PHP, I am in no way
>> determining what you (or anyone else) may or may not do. You are a
>> free individual and free to choose the programming language and
>> paradigm that is best suited to your purposes.
>
> right! that's saying "you're free to leave behind the tool you've
> chosen for another one, because really, that tool should not start to
> support things that i dont happen to have a use for."

Are you saying you are not free? You are free to do so much in this
world, all it takes is backbone to make the choice sometimes.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote:
>> Rene Veerman wrote:
>>
>>> popular : facebook youtube etc
>>>
>> Rene, I must be missing something here. That sort of size implies
>> millions in advertising revenue, so why are we discussing how much
>> performance we can squeeze out of a single box? I mean, I'm all for
>> efficient use of system resources, but if I have a semi-scalable
>> application, it's a lot easier just getting another box than trying to
>> change the implementation language. OTOH, if my design is not
>> scalable, it's probably also easier to redo it than trying to change
>> the implementation language.
>
> again:
> a) you're determining the contents of my toolset, without it affecting
> you at all. the way you want it php will degrade into a toy language.
> b) i will aim for all possible decreases in development time and
> operating costs during, not only in the grow phase but also in hard
> economic times. any business person knows why.
>
>>> and you're still trying to impose a toolset on me.
>> I didn't think I was - you're the one who seem to be fixed on PHP as the
>> only solution, and advocating that it be enhanced to suit your
>> purposes.
>
> no, php is just my toolset of choice, and i think it should grow with
> the times and support threading and shared memory.
> maybe even a few cool features to enable use-as-a-cloud.

Why are you imposing a toolset on the developers of PHP? Are you even
subscribed to internals? Have you even thought of creating a patch? It's
one thing to debate the merits of a tool, it's another to insist that it
be added because you think php needs to "grow up".

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> exactly. the knock-on problems you mentioned are well solved and well
> documented.
> realtime programmers using threads have to get their heads around it
> on their first realtime project.
>
> i don't like doing my code in c(++), or worse; having to interface
> between c(++) and php.
> i chose php because my code can stay close to simple english that way.
> what you're suggesting is highly intrusive in my work-style, one that
> you're not affected by at all.
> in fact if you make things more difficult for me, i have less time to
> release opensource code of my own.

Someone call a Waaaaaaaaaaaaaaaaaaah-mbulance!

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Per Jessen wrote:
> Rene Veerman wrote:
>
>> again:
>> a) you're determining the contents of my toolset, without it affecting
>> you at all. the way you want it php will degrade into a toy language.
>
> Rene, it seems to me that you and I are advocating two opposite
> positions on the topic of threading in PHP, so aren't we both trying to
> determine the contents of each others toolset?

*bingo* It should be a debate about the merits of each position. Not a
pissing contest.

>> b) i will aim for all possible decreases in development time and
>> operating costs during, not only in the grow phase but also in hard
>> economic times. any business person knows why.
>
> Given that the lifetime effort (=cost) of any software project is
> divided into 25% development and 75% maintenance, you really ought to
> focus on the latter. If you want more performance at a minimal cost,
> surely you should opt to write in a compiled language where you'll get
> far more bang for the buck.

Oh no, now you're suggesting he change his management focus :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> On Wed, Mar 24, 2010 at 11:13 AM, Per Jessen wrote:
>> Rene Veerman wrote:
>>
>>> again:
>>> a) you're determining the contents of my toolset, without it affecting
>>> you at all. the way you want it php will degrade into a toy language.
>> Rene, it seems to me that you and I are advocating two opposite
>> positions on the topic of threading in PHP, so aren't we both trying to
>> determine the contents of each others toolset?
>>
>
> Per: that's EXACTLY the point.
> You are determining it for me, i'm not for you.
> Simply because you dont have to use the language features you atm
> think you don't need in php.

Actually, no. You are determine aspects of the toolset as it stands. To
add threading is not a benign additon because we can choose to use it or
not. If added it would affect the future irrevocably since undoubtedly
we would need to maintain someone's code that contains threads because
they didn't understand the shared nothing nature of PHP.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> php is not a hammer, its a programming language.

It's hard to discuss anything with someone who doesn't comprehend a
metaphor.

> one that i feel needs to stay ahead of the computing trend if it is to
> be considered a language for large scale applications.

Personification of PHP doesn't make your argument any more salient. PHP
isn't trying to stay ahead of anything. People are using it to solve
problems, not to meet some phantom ideal of a "computing trend" threshold.

> but you nay-sayers here have convinced me; i'll be shopping for
> another language with which to serve my applications and the weboutput
> they produce..
>
> thanks for opening my eyes and telling to abandon ship in time.

Obviously we didn't open your eyes.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Rene Veerman wrote:
> unless the actual php development team would like to weigh in on this
> matter of course.

Wrong list. Subscribe to internals.

> yes, i do consider it that important.

> these nay-sayers usually also lobby the dev-team to such extent that
> these features would actually not make it into php.

It's a debate. The dev team consider proposals and weigh in on the
merits. I was a proponent for goto support during the development of PHP
5. We now have it. If you arguments are valid and there's no technical
issue preventing it, and there's someone with time and skill to created
the functionality, then it will happen. If not then it won't. I've seen
many things added to PHP and I've watched and participated in the
threads on internals that have lead to many new features. This is open
source, opinions matter, but personal attacks and poor argument do not
really make the cut.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Arno Kuhl wrote:
> -----Original Message-----
> From: Rene Veerman [mailto:rene7705@gmail.com]
> Sent: 24 March 2010 11:31 AM
> Subject: Re: [PHP] Will PHP ever "grow up" and have threading?
>
> thanks for opening my eyes and telling to abandon ship in time.
>
> ===============================
>
> Bye, enjoy the swim...
>
> Maybe by the time you get back to shore you'll realise how dumb it would be
> if a sailor complained that his yatch didn't behave like a hovercraft, or
> his passenger ship couldn't carry a million barrels of oil, or his tug boat
> was useless at pulling a skier... Just how much (or little) development
> experience do you have?

Hmmm... he had trouble with metaphors earlier, I'm not sure he'll
understand the above :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

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"...

PHP has excellent support for extensions. I've written several C
extensions int he past for my own personal use. Even facebook punts some
stuff to C extensions that they just plug right into PHP.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Op 3/24/10 10:40 AM, Rene Veerman schreef:
> I subscribe to this list to share tips on software designs.
>
> Getting and keeping your respect i'm not even interested in.
>
> I'm interested in the quality of your tips on problems i post, as tips can
> lead faster to products, leads to money, leads to my personal freedom and
> options in life.
> Respect cannot be used to buy bread and butter.
>

Someone who respects you will buy you a sandwich if you need it.

But seemingly you're only interested in leveraging other peoples time and
experience to further your own career, good luck with that around here.

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

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

Rene Veerman wrote:
> I subscribe to this list to share tips on software designs.
>
> Getting and keeping your respect i'm not even interested in.
>
> I'm interested in the quality of your tips on problems i post, as tips can
> lead faster to products, leads to money, leads to my personal freedom and
> options in life.
> Respect cannot be used to buy bread and butter.

Then you haven't heard about how much value goodwill can add when
selling a company :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Per Jessen wrote:
> Tommy Pham wrote:
>
>> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas
>> wrote:
>>> Give us a real example of why you think it should be
>>> supported and I guarantee we can come up with a way to get you what
>>> you want without requiring massive changes to the core of your chosen
>>> tool. And if we can't then you may actually convince us that
>>> threading would be a valuable feature to have available.
>> I did give a real life example, ie e-commerce site mentioned earlier.
>
> How many _concurrent_ users do you expect - which order of magnitude:
> 10,100,1000,10000?
>
>> Amazon has the similar features of my example except they have about
>> 30 million products without (i18n). Their I18n is different web
>> server & db & site layout which is completely different from my
>> example.
>
> Understood.
>
>> Setting I18n aside, having the same features as my example
>> with about 30 million products to response in about 3 seconds is very
>> good. Even though my example only have about 750,000 products, the
>> translations for the requested languages makes it into 750,000 * 6 =
>> 4,500,000 rows of product descriptions. This is e-commerce site not a
>> data warehouse/mining. What would happen then if the site has over
>> 20,000,000 product skus with similar language translations for the
>> descriptions? 20,000,000 * 6 = ... big number to me...
>
> Thinking out loud - maybe it would make sense to have a separate
> database instance/machine per language? That would enable to you to
> start them all on one machine, but shift to another once the load
> increases. (not dynamically, but with time).
> If that's not a feasible option, maybe a mysql cluster or a very large
> database server?

Stick it in the same machine, use replication. Force specific language
read queries to specific machines so that the database server cache is
primed for that language. This way you're still only maintaining one
database.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

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

Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote:
>> Tommy Pham wrote:
>>>> How exactly will threading in PHP help with the size of the database?
>>>> That makes no sense to me, please help me understand how you think threading
>>>> will help in this scenario.
>>> Looking at my example, not just the rows.... There are other features
>>> that require queries to a DB for simple request of a category by a
>>> shopper, instead of running those queries in series, running them in
>>> parallel would yield better response time.
>>>
>>>> Database size issues are tackled with clustering, caching and DB
>>>> optimisation. Threading in the language accessing the DB has no advantage
>>>> here.
>>> Yes, it does. As mentioned several times, instead of running the
>>> queries in series, run them in parallel. If each of the queries takes
>>> about .05 to .15 seconds. How long would it take to run them in
>>> serial? How long do you it take to run them in parallel?
>> Any you have a database that can actually handle that?
>> If the database is taking 0.1 seconds per query, and you have 10 queries,
>> then getting the data is going to take 1 second to generate. If you want
>> some slow query to be started, and come back for the data later, then I
>> thought we already had that? But again this is part of the database driver
>> anyway. No need to add threading to PHP to get the database connection to
>> pull data in the most efficient way. And one does not write the driver in
>> PHP? We are using C there already?
>>
>> --
>> Lester Caine - G8HFL
>> -----------------------------
>
> Exactly my point. 10 queries taking .1 second each running in serial
> is 1 second total. How long would it take to run all those same
> queries simultaneously??? What's so difficult about the concept of
> serial vs parallel?

You seem to think that those 10 queries are happening in isolation. What
about the other 100 concurrent users all smacking the db server with 10
queries. The db server is just going to queue them and serially process
them as each of it's own processing threads become free. In high
concurrency situations threading isn't going to make much difference, in
fact it's very likely to decrease performance because now you've added
the overhead of thread concurrency handling in PHP when the db server is
already handling this issue between the multiple web server requests.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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