Everything

php

Multithreading

php.internals

Bart de Boer

20 years ago

Dear PHP creators,

I was wondering. (And I'm probably the 1000th person asking this.) With
all the multiple-core processors and servers popping up lately, are
there any future (or current) plans for multithreading in PHP?

It's not unlikely to have a PHP script that, for example, needs to send
an email, do some database transactions and perhaps communnicate with a
web service simultaneously. In such situations where the script needs to
wait for multiple external actions it could really improve performance.

I know there are other ways to do it. (It's possible to do
"multithreading" with sockets.) Still I think it would be cool if there
would be native support. As a fanatic PHP programmer it has always been
something that I envy about in other languages.

Bart

Rasmus Lerdorf

20 years ago

Bart de Boer wrote:

> Dear PHP creators,
>
> I was wondering. (And I'm probably the 1000th person asking this.) With
> all the multiple-core processors and servers popping up lately, are
> there any future (or current) plans for multithreading in PHP?
>
> It's not unlikely to have a PHP script that, for example, needs to send
> an email, do some database transactions and perhaps communnicate with a
> web service simultaneously. In such situations where the script needs to
> wait for multiple external actions it could really improve performance.
>
> I know there are other ways to do it. (It's possible to do
> "multithreading" with sockets.) Still I think it would be cool if there
> would be native support. As a fanatic PHP programmer it has always been
> something that I envy about in other languages.

There are no plans for this.  Asynchronous mechanisms are generally a
much more efficient way to do this stuff.

-Rasmus

Bart de Boer

20 years ago

Rasmus Lerdorf wrote:

> Bart de Boer wrote:
>> Are there any future (or current) plans for multithreading in PHP?
>
> There are no plans for this.  Asynchronous mechanisms are generally a
> much more efficient way to do this stuff.
>
> -Rasmus

With asynchronous I'm asuming you mean mechanisms where you call other
scripts (web services) from within the main script? Besides the extra
overhead, scripts and code, I guess this is a good alternative.

The thing is. I'm currently working on a project that I'm forced to do
with *cough* M$ C# *cough*. I hate everything about it except for the
threading. Which is... not so bad. :) With just a teeny bit of extra
code I'm able to call some functions or methods in seporate threads and
wait untill they're done.

Just think it would be nice... :)

Andrei Zmievski

20 years ago

Exactly. Something based on libevent would be nice.

-Andrei

On Dec 7, 2005, at 4:49 PM, Rasmus Lerdorf wrote:

Wez Furlong

20 years ago

pecl/event is available for download... ;-)

--Wez.

On 12/7/05, Andrei Zmievski <andrei@gravitonic.com> wrote:

Bart de Boer

20 years ago

Thank you all, for the feedback. Some solutions are new to me. So, I'll
be taking a deeper look into those options.

I have to say that they all still sound a bit like work-arounds.
(Although this could very well be due to my unworthy knowledge. ;) ) I
still think it would be nice if there would be something natively in PHP
to which you could say: "This is for doing multithreading in PHP". It
wouldn't nessacerily have to work exaclty the same way as it does with
other languages. Maybe something like PCNTL that works cross-platform.
Or something like what Sara is working on. Or maybe a special fork()
function that minimizes overhead and has some PHP-optimized feedback
features?

Loads of respect to you all!,

Bart

Lukas Smith

20 years ago

Hi,

I really do not see the point is worrying all too much about multi
threading in PHP. Writing proper multi threaded code is hard and why
bother? Your server is going to be busy doing tons of other things at
the same time. So all your CPU's and cores should have plenty of things
to do. Also PHP is a glue language, so by this virtue it should not
require multi threading in order to get decent performance/latency for a
request. Most of the work is performed elsewhere anyways (like inside
your database server).

Of course you can use PHP to write deamons, hardcore number crunching,
desktop apps. But this should never dominant decisions about the core of
the language. So I welcome whatever Sara is playing with that can be
added as an extension to PHP.

regards,
Lukas

Bart de Boer

20 years ago

> I really do not see the point is worrying all too much about multi
> threading in PHP. Writing proper multi threaded code is hard and why
> bother? Your server is going to be busy doing tons of other things at
> the same time. So all your CPU's and cores should have plenty of things
> to do. Also PHP is a glue language, so by this virtue it should not
> require multi threading in order to get decent performance/latency for a
>

History tells us that, as hardware performance increases, people will
always utalise the extra power by creating more demanding scripts (and
software). We most likely wouldn't do the things we do today if we still
had the hardware we had back when PHP3 was out. Since it currently seems
to be the trend that performance gains are made by adding more cores to
the processor, I think the server software must adjust to be able to
utalise this. I have a feeling we'll be seeing a lot more multithreading
software in the near future.

Although you're right that the webserver already does multithreading
itself. And PHP is able to hitch a ride on this capability. I just think
that maybe, if the multithreading trend really takes off, it may one day
become a necessity for PHP to support this. If so, I don't think it will
be in the near future. So there's still plenty of time to think about
this. :)

Of course this is all "what-if" speculation. But I thought it's worth
noting at least. :)

Andrei Zmievski

20 years ago

It must be Christmas time.

- A

On Dec 7, 2005, at 7:17 PM, Wez Furlong wrote:

Ilia A.

20 years ago

You don't need threads, you can use fork() for that. On *nix systems it
is very fast, nearly as fast as threads and much safer to boot. And you
can already do forking in PHP via PCNTL extension's pcntl_fork() function.

Ilia

Bart de Boer

20 years ago

Ilia Alshanetsky wrote:

> You don't need threads, you can use fork() for that. On *nix systems it
> is very fast, nearly as fast as threads and much safer to boot. And you
> can already do forking in PHP via PCNTL extension's pcntl_fork() function.
>
> Ilia

That sounds sufficient enough. Although I guess this only works on *nix
systems? Platform independence is one of the main reasons I prefer PHP
over other languages.

Wez Furlong

20 years ago

Try proc_open().

--Wez.

On 12/7/05, Bart de Boer <bart@mediawave.nl> wrote:

Joseph Crawford

20 years ago

php should defenatly in the future support multi-threading especially if
they want to prove you can do desktop apps with php and not just web apps ;)

--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
1-802-671-2021
codebowl@gmail.com

Rasmus Lerdorf

20 years ago

Joseph Crawford wrote:

> php should defenatly in the future support multi-threading especially if
> they want to prove you can do desktop apps with php and not just web apps ;)

Which is not something we have ever stated to be a goal.

-Rasmus

Lester Caine

20 years ago

Rasmus Lerdorf wrote:

>> php should defenatly in the future support multi-threading especially if
>> they want to prove you can do desktop apps with php and not just web
>> apps ;)
>
> Which is not something we have ever stated to be a goal.

May be not, but when has that stopped people doing things ;)
Even when you TELL them something does not work, they will try anyway :(

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.

Ilia A.

20 years ago

Bart de Boer wrote:

> Ilia Alshanetsky wrote:
>
>> You don't need threads, you can use fork() for that. On *nix systems it
>> is very fast, nearly as fast as threads and much safer to boot. And you
>> can already do forking in PHP via PCNTL extension's pcntl_fork()
>> function.
>>
>> Ilia
>
>
> That sounds sufficient enough. Although I guess this only works on *nix
> systems? Platform independence is one of the main reasons I prefer PHP
> over other languages.

fork() works on windows as well, but on Win32 forking is MUCH slower
then threads.

Ilia

Bart de Boer

20 years ago

> fork() works on windows as well, but on Win32 forking is MUCH slower
> then threads.
>
> Ilia

With fork() you mean using exec() to call php with another script,
right? Because I can't seem to find the fork() function anywhere. :|

Sara Golemon

20 years ago

> I was wondering. (And I'm probably the 1000th person asking this.) With
> all the multiple-core processors and servers popping up lately, are
> there any future (or current) plans for multithreading in PHP?
>

I've got two...well...threads... going on this concept.... One is a very
non-true-threading apprach which involves a combination of ticks and
Runkit_Sandbox which I hope to get around to sooner rather than later.

The other is a longer-range plan designed to work specifically with
apache2-worker (though perhaps generalized to work with other threaded
SAPIs) to actually use some of those extra threads to link multiple real
interpreters together (allowing one request chain to start/shutdown another
in a sibling relationship -- as opposed to Runkit_Sandbox which is purely
parent/child).  Don't look for this anytime soon though.  It's in my
"wouldn't that be kinda cool" bin of projects to work on next to oggtheora
and a few unnamed beasts...

-Sara

Bart de Boer

20 years ago

Sara Golemon wrote:

>I've got two...well...threads... going on this concept.... One is a very
>non-true-threading apprach which involves a combination of ticks and
>Runkit_Sandbox which I hope to get around to sooner rather than later.
>
>The other is a longer-range plan designed to work specifically with
>apache2-worker (though perhaps generalized to work with other threaded
>SAPIs) to actually use some of those extra threads to link multiple real
>interpreters together (allowing one request chain to start/shutdown another
>in a sibling relationship -- as opposed to Runkit_Sandbox which is purely
>parent/child).  Don't look for this anytime soon though.  It's in my
>"wouldn't that be kinda cool" bin of projects to work on next to oggtheora
>and a few unnamed beasts...
>
>-Sara
>
>

"kinda cool" to hear somebody is experimenting with this... :)...