Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.
My question is if there's any intent to have multi-threading support
to PHP in a future version, like PHP7.
I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
the apps to be self-content with no needs and no dependency of
external daemons like cron.
So, what's the opinion of the PHP maintainers?
Regards,
--
Felipe Ribeiro
felipernb@gmail.com
http://feliperibeiro.com
83 9979-3161
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.My question is if there's any intent to have multi-threading support
to PHP in a future version, like PHP7.I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
the apps to be self-content with no needs and no dependency of
external daemons like cron.
I have spoken to a few people lately about this and to be honest, the
opinion I get out of multi threading in php is basically "no one cares
doing it, no internals need it so badly that he'll implement it, and
find people to maintain it"
Opening this thread is a good idea I think, after this I'll gather all
ideas and comments and make a good post out of it.
So, what's the opinion of the PHP maintainers?
Regards,
--
Felipe Ribeiro
felipernb@gmail.com
http://feliperibeiro.com
83 9979-3161--
--
David,
Re-read what you are replying.
David Coallier wrote:
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.My question is if there's any intent to have multi-threading support
to PHP in a future version, like PHP7.I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
the apps to be self-content with no needs and no dependency of
external daemons like cron.I have spoken to a few people lately about this and to be honest, the
opinion I get out of multi threading in php is basically "no one cares
doing it, no internals need it so badly that he'll implement it, and
find people to maintain it"Opening this thread is a good idea I think, after this I'll gather all
ideas and comments and make a good post out of it.So, what's the opinion of the PHP maintainers?
Regards,
--
Felipe Ribeiro
felipernb@gmail.com
http://feliperibeiro.com
83 9979-3161--
David,
hope you don't mind me asking for a bit more info, I was always under
the impressions that a thread is defined as (quote wiki)
"Threads are a way for a program to fork (or split) itself into two or
more simultaneously (or pseudo-simultaneously) running tasks. Threads
and processes differ from one operating system to another but, in
general, a thread is contained inside a process and different threads of
the same process share some resources while different processes do not."
and php supports pcntl_fork along with signal handlers and interprocess
communication via functions like or stream_socket_pair.
as such if I set up a cli app with parent and child processes
(?threads), then isn't this multithreading in php?
I know this strictly isn't the place for such questions, but I hope you
won't mind enlightening me a little on the matter.
Many Regards in advance,
Nathan
hope you don't mind me asking for a bit more info, I was always under
the impressions that a thread is defined as (quote wiki)"Threads are a way for a program to fork (or split) itself into two or
more simultaneously (or pseudo-simultaneously) running tasks. Threads
and processes differ from one operating system to another but, in
general, a thread is contained inside a process and different threads of
the same process share some resources while different processes do not."and php supports pcntl_fork along with signal handlers and interprocess
communication via functions like or stream_socket_pair.as such if I set up a cli app with parent and child processes
(?threads), then isn't this multithreading in php?I know this strictly isn't the place for such questions, but I hope you
won't mind enlightening me a little on the matter.
it is not multithreading.
multithreading means that a process starts several "threads" which
work simulatenously and share local resources (such as variables,
dynamically created functions/classes, database connections, etc.)
pcntl_fork creates several processes, which can communicate, but still
has their own sets of local resources
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Alexey Zakhlestin wrote:
hope you don't mind me asking for a bit more info, I was always under
the impressions that a thread is defined as (quote wiki)"Threads are a way for a program to fork (or split) itself into two or
more simultaneously (or pseudo-simultaneously) running tasks. Threads
and processes differ from one operating system to another but, in
general, a thread is contained inside a process and different threads of
the same process share some resources while different processes do not."and php supports pcntl_fork along with signal handlers and interprocess
communication via functions like or stream_socket_pair.as such if I set up a cli app with parent and child processes
(?threads), then isn't this multithreading in php?I know this strictly isn't the place for such questions, but I hope you
won't mind enlightening me a little on the matter.it is not multithreading.
multithreading means that a process starts several "threads" which
work simulatenously and share local resources (such as variables,
dynamically created functions/classes, database connections, etc.)pcntl_fork creates several processes, which can communicate, but still
has their own sets of local resources
Thankyou for taking the time to shed some light on the mater for me; I'd
missed the all vital "sharing resources" part of the concept, probably
because (if I'm correct in saying) php shares memory of
variables/classes/resources between parent and child processes until a
write occurs, at which point a new version of the aforementioned is
created. [please correct if wrong].
Would I therefore be correct in assuming the following:
In PHP we can create mutli-process(tasking) applications that have most
of the benefits of multi-threaded applications and less bugs.
I'm working on the premise that a processor can only run so fast, so
multithreading say 100k calculations would not speed up and application,
if anything it would add overhead, and slow it down. The only way to
speed up such an application would be to throw more hardware at the
problem (be it servers or processors).
Meaning that the only time multi-process/multi-threading would have any
positive bearing on an application would be when dealing with things
such as external resources, due to the slower access times of these
external resources we find threads/processes "waiting" for the resource
to be usable (fully downloaded/opened) - in such a situation
multi-threading has it's distinct advantages.
However forking an app (?multi-process) can already achieve the same
results, the only difference being that we may have a few duplicate
classes/variables around the application doing it this way (subject to
us not taking the time to define all "shared" resources in the parent
process.
If I'm correct in all of the above, then I'd personally think that we
don't need multithreading in PHP, however a neat(er) predefined method
of interprocess communication would be beneficial.
Thoughts/Corrections?
Regards
Nathan
Thankyou for taking the time to shed some light on the mater for me; I'd
missed the all vital "sharing resources" part of the concept, probably
because (if I'm correct in saying) php shares memory of
variables/classes/resources between parent and child processes until a
write occurs, at which point a new version of the aforementioned is
created. [please correct if wrong].
pcntl_fork() uses fork() call which is implemented in OS. Forked
process is a copy of parent process, which means, that it occupies
similiar amount of memory. Each time you "fork" your memory usage gets
bigger
Would I therefore be correct in assuming the following:
In PHP we can create mutli-process(tasking) applications that have most
of the benefits of multi-threaded applications and less bugs.I'm working on the premise that a processor can only run so fast, so
multithreading say 100k calculations would not speed up and application,
if anything it would add overhead, and slow it down. The only way to
speed up such an application would be to throw more hardware at the
problem (be it servers or processors).
If your task is CPU-bound, you can't do much, but give it more hadrware.
(we are not talking about optimization of algorithms here)
Meaning that the only time multi-process/multi-threading would have any
positive bearing on an application would be when dealing with things
such as external resources, due to the slower access times of these
external resources we find threads/processes "waiting" for the resource
to be usable (fully downloaded/opened) - in such a situation
multi-threading has it's distinct advantages.However forking an app (?multi-process) can already achieve the same
results, the only difference being that we may have a few duplicate
classes/variables around the application doing it this way (subject to
us not taking the time to define all "shared" resources in the parent
process.
Multithreading can be dramatially good for memory-bound tasks.
It is possible to say (although, this is oversimplification), that
threads are "light processes".
They allow to execute a lot of parallel tasks with less overhead
If I'm correct in all of the above, then I'd personally think that we
don't need multithreading in PHP, however a neat(er) predefined method
of interprocess communication would be beneficial.
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Felipe Ribeiro wrote:
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.My question is if there's any intent to have multi-threading support
to PHP in a future version, like PHP7.I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
the apps to be self-content with no needs and no dependency of
external daemons like cron.So, what's the opinion of the PHP maintainers?
Just an uninformed thought: maybe the existing TSRM framework could be
leveraged to provide some simple multithreading support to the user.
User threads could get their own set of engine globals, initialised in
the same way that multithreaded SAPIs do it. Inter-thread communication
would be handled by a small set of thread-safe transfer functions, which
would copy data between distinct memory pools. Threads could be started
by specifying a string or file to compile and execute in the new
environment. It'd be heavyweight compared to an ordinary threaded
application, but lightweight compared to multiprocessing by shelling out
to subsidiary scripts via the CLI SAPI.
Then incremental development could head in the direction of more
efficient data transfer, oparray sharing, and support for threaded
concepts like locks and worker pools.
-- Tim Starling
Hi!
Just an uninformed thought: maybe the existing TSRM framework could be
leveraged to provide some simple multithreading support to the user.
TSRM is meant to support "share nothing" in threaded environment.
Multi-threading should support sharing data (including locking &
synchronization) which is quite different business.
It may be easier to do pseudo-multithreading a-la Python, where there's
only one thread running at each moment of time, but they can switch when
other threads are waiting for something like I/O or some event. That
would require some work for defining engine state and enabling
switching, but it's easier than full multithreading support.
Unfortunately, as for now nobody showed real interest in doing that.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
Just an uninformed thought: maybe the existing TSRM framework could
be leveraged to provide some simple multithreading support to the user.TSRM is meant to support "share nothing" in threaded environment.
Multi-threading should support sharing data (including locking &
synchronization) which is quite different business.It may be easier to do pseudo-multithreading a-la Python, where
there's only one thread running at each moment of time, but they can
switch when other threads are waiting for something like I/O or some
event. That would require some work for defining engine state and
enabling switching, but it's easier than full multithreading support.
Unfortunately, as for now nobody showed real interest in doing that.
I'm saying that you could make multiple "share nothing" instances
available to the user, for a programming model intermediate between
multiprocessing and traditional threading.
Python-style multithreading wouldn't be useful for the applications I
have in mind.
-- Tim Starling
well, there is http://pecl.php.net/package/threads
it was never finished, thogh
Here's the thread about it, from last august:
http://thread.gmane.org/gmane.comp.php.pecl.devel/3996
Hello,
I've been reading this list for a couple of months and I have a
question that might have already been discussed here before and I
haven't seen, so please apologize me.My question is if there's any intent to have multi-threading support
to PHP in a future version, like PHP7.I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
the apps to be self-content with no needs and no dependency of
external daemons like cron.So, what's the opinion of the PHP maintainers?
Regards,
--
Felipe Ribeiro
felipernb@gmail.com
http://feliperibeiro.com
83 9979-3161--
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Hi!
I know multi-threading is an enormous source of bugs, but I think it
does offer a good support for large-scale apps considering the
background processes and event-driven programming, and also allowing
Multithreading does not fit well in the set of assumptions PHP engine is
built on (though as for PHP language itself, I don't think there are
assumptions that contradict threads) so it would be quite hard to do it
on existing engine. It might be easier to do on some non-standard
implementations, but I wouldn't hold my breast about standard engine -
unless somebody comes forward and surprises us.
the apps to be self-content with no needs and no dependency of
external daemons like cron.
I'm not sure how cron enters here but if what you need is scheduling
capabilities then there are products implementing this, e.g. in Zend
Platform.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com