Richard Quadling wrote:
> Hi.
> As I understand things, one of the main issues in the "When will PHP
> grow up" thread was the ability to issue multiple queries in parallel
> via some sort of threading mechanism.
> Due to the complete overhaul required of the core and extensions to
> support userland threading, the general consensus was a big fat "No!".
> As I understand things, it is possible, in userland, to use multiple,
> non-blocking sockets for file I/O (something I don't seem to be able
> to achieve on Windows
> Can this process be "leveraged" to allow for non-blocking queries?
> Being able to throw out multiple non-blocking queries would allow for
> the "queries in parallel" issue.
> My understanding is that at the base level, all queries are running on
> a socket in some way, so isn't this facility nearly already there in
> some way?


"Threading" is only realistically needed when you have to get data from
multiple sources; you may as well get it all in parallel rather than
sequentially to limit the amount of time your application / script is
sitting stale and not doing any processing.

In the CLI you can leverage forking to the process to cover this.

When working in the http layer / through a web server you can leverage
http itself by giving each query its own url and sending out every
request in a single http session; allowing the web server to do the
heavy lifting and multi-threading; then you get all responses back in
the order you requested.

In both environments you can use non-blocking sockets to do your
communications with other services and 3rd parties; whilst you can only
process the the returned data sequentially, at least all the foreign
services are doing their work at the same time. Which cuts down user
perceived runtime and the "real" time (since your own php code can
ultimately only run X fast).

A short example would be to consider using the non blocking mysql query
function against multiple connections; this way mysql is doing the heavy
lifting in parallel and you are processing results sequentially.

In all scenarios /all/ of the contributing aspects have to be considered
though; the number of open connections, how much extra weight that puts
on the server (having a knock on effect on other processes), what
happens when one of the "threads" fails and so forth.

Normally there are many different ways to handle the same problem
though; such as views at the rdbms level, publishing / caching output,
or considering if you are still in the right language - sometimes
factoring bits which require multi threading in to different languages
and services lends to a nicer solution.

And finally, more often than not, the same problem can be addressed by
taking the final output, then working out how to produce it in reverse;
many queries can be turned in to one, data can be normalised higher up
the chain, sorting can occur in php rather than in the rdbms and many
more solutions. Always many ways to skin the cat :)


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to