Alexey Zakhlestin wrote:
On 2/21/08, Nathan Rixham <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
