From: Rene Veerman on
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 <degeberg(a)> wrote:
> On Wed, Mar 24, 2010 at 12:27, Rene Veerman <rene7705(a)> 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
From: Peter Lind on
On 24 March 2010 12:14, Tommy Pham <tommyhp2(a)> wrote:
> On Wed, Mar 24, 2010 at 4:09 AM, Peter Lind <peter.e.lind(a)> wrote:
>> On 24 March 2010 12:04, Tommy Pham <tommyhp2(a)> wrote:
>>> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine <lester(a)> 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
>>>> -----------------------------
>>>> Contact -
>>>> L.S.Caine Electronic Services -
>>>> EnquirySolve -
>>>> Model Engineers Digital Workshop -
>>>> Firebird -
>>>> --
>>>> PHP General Mailing List (
>>>> To unsubscribe, visit:
>>> 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.
> 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 (
>>> To unsubscribe, visit:
>> --
>> <hype>
>> WWW: /
>> LinkedIn:
>> Flickr:
>> BeWelcome: Fake51
>> Couchsurfing: Fake51
>> </hype>

WWW: /
BeWelcome: Fake51
Couchsurfing: Fake51
From: Robert Cummings on
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 :)

Application and Templating Framework for PHP
From: Robert Cummings on
Rene Veerman wrote:
> popular : facebook youtube etc

I doubt very much you're popular like facebook. Nothing is as popular as

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.

Application and Templating Framework for PHP
From: Robert Cummings on
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.

Application and Templating Framework for PHP