php-general Digest 31 Oct 2012 16:27:54 -0000 Issue 8027
Topics (messages 319624 through 319637):
Multithreading for OOP PHP
319624 by: Florian Müller
319626 by: marco.behnke.biz
319627 by: Ovidiu Farauanu
319628 by: Ovidiu Farauanu
319629 by: Florian Müller
319630 by: marco.behnke.biz
319631 by: marco.behnke.biz
319632 by: marco.behnke.biz
319633 by: Alessandro Pellizzari
319634 by: Alessandro Pellizzari
319635 by: Alex Nikitin
319636 by: Tommy Pham
319637 by: Alex Nikitin
Re: TURBOPY cloud framework + IDE beta available NOW
319625 by: marco.behnke.biz
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hi guys
I was wondering, what actually the reason is that PHP itself does not support
multi-threading?
I guess this would be realizable, or not? If not, why?
Maybe this is a stupid question, but still somehow interesting. Realization in
a way as Java does (or just something in that way) would actually be a very
nice thing, don't you think?
Thank you for your answers :)
Florian
--- End Message ---
--- Begin Message ---
"Florian Müller" <florian-muel...@outlook.com> hat am 31. Oktober 2012 um 07:58
geschrieben:
> Hi guys
> I was wondering, what actually the reason is that PHP itself does not support
> multi-threading?
> I guess this would be realizable, or not? If not, why?
> Maybe this is a stupid question, but still somehow interesting. Realization in
> a way as Java does (or just something in that way) would actually be a very
> nice thing, don't you think?
> Thank you for your answers :)
That is because most parts of the PHP code is not threadsafe.
> Florian
>
--
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
--- Begin Message ---
Hello Florian,
Usually you want to run a PHP script in two different environments:
1. inside a webserver
2. in a command line interface
For a web application, the application server does the work for you.
It is the server job to have a thread pool and balance it correctly.
So you don't need threads for the same reason threads are prohibited in
Java EE containers.
I assume that you don't fork multiple threads for every single HTTP request
inside a Java Servlet, for instance.
When you are inside a command line usually you start processes instead of
threads.
And this is fully supported by PHP.
However, there are several reasons in choosing processes instead of threads.
Several high-level programming languages are starting OS processes for
language threads.
But maybe this is not on our topic now.
But I am wondering what do you mean by "multithreading support"?
Do you need library functions as synchronization primitives?
Or you are talking about something like "synchronized" keyword?
On Wed, Oct 31, 2012 at 8:58 AM, Florian Müller <florian-muel...@outlook.com
> wrote:
> Hi guys
> I was wondering, what actually the reason is that PHP itself does not
> support multi-threading?
> I guess this would be realizable, or not? If not, why?
> Maybe this is a stupid question, but still somehow interesting.
> Realization in a way as Java does (or just something in that way) would
> actually be a very nice thing, don't you think?
> Thank you for your answers :)
> Florian
>
--
Cu respect / Best regards,
Dipl.-Ing. Ovidiu Farauanu
--- End Message ---
--- Begin Message ---
Yes Marco has right.
But more than that, OOP is mainly designed to run in a single threaded
environment and it is not the best idea to be used for concurrent
programming because you will need synchronization everywhere and this slows
down the code, but also ask for a lot of other troubles.
I think functional paradigm is more better suited for concurrent
programming, and there are some nice features in PHP 5.4
please see "Closures" and how "callbacks" can be used in PHP. Functional
features are prepared for Java 8, and they are already in C++11.
On Wed, Oct 31, 2012 at 10:44 AM, ma...@behnke.biz <ma...@behnke.biz> wrote:
> "Florian Müller" <florian-muel...@outlook.com> hat am 31. Oktober 2012 um
> 07:58
> geschrieben:
> > Hi guys
> > I was wondering, what actually the reason is that PHP itself does not
> support
> > multi-threading?
> > I guess this would be realizable, or not? If not, why?
> > Maybe this is a stupid question, but still somehow interesting.
> Realization in
> > a way as Java does (or just something in that way) would actually be a
> very
> > nice thing, don't you think?
> > Thank you for your answers :)
>
> That is because most parts of the PHP code is not threadsafe.
>
> > Florian
> >
> --
> Marco Behnke
> Dipl. Informatiker (FH), SAE Audio Engineer Diploma
> Zend Certified Engineer PHP 5.3
>
> Tel.: 0174 / 9722336
> e-Mail: ma...@behnke.biz
>
> Softwaretechnik Behnke
> Heinrich-Heine-Str. 7D
> 21218 Seevetal
>
> http://www.behnke.biz
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Cu respect / Best regards,
Dipl.-Ing. Ovidiu Farauanu
--- End Message ---
--- Begin Message ---
I actually tought about just the same structures as Java uses(something in this
way:
Thread t = new Thread(new Runnable() { public void run() { ...blabla
}}
I thought this would actually be a good benefit if PHP supported this. It's
just as we sometimes use PHP for doing some big Server works (e.g. database
copying or something) and it would be nice to controll by yourself which Thread
(or process) does which part of the job.
For normal HTTP calls which must be handled within milliseconds, this actually
does not make sense, that's right ;)
> From: ovidiugabr...@gmail.com
> Date: Wed, 31 Oct 2012 10:59:28 +0200
> To: php-gene...@lists.php.net
> Subject: [PHP] Multithreading for OOP PHP
>
> Hello Florian,
>
> Usually you want to run a PHP script in two different environments:
> 1. inside a webserver
> 2. in a command line interface
>
> For a web application, the application server does the work for you.
> It is the server job to have a thread pool and balance it correctly.
> So you don't need threads for the same reason threads are prohibited in
> Java EE containers.
> I assume that you don't fork multiple threads for every single HTTP request
> inside a Java Servlet, for instance.
>
> When you are inside a command line usually you start processes instead of
> threads.
> And this is fully supported by PHP.
> However, there are several reasons in choosing processes instead of threads.
> Several high-level programming languages are starting OS processes for
> language threads.
> But maybe this is not on our topic now.
>
> But I am wondering what do you mean by "multithreading support"?
> Do you need library functions as synchronization primitives?
> Or you are talking about something like "synchronized" keyword?
>
>
>
> On Wed, Oct 31, 2012 at 8:58 AM, Florian Müller <florian-muel...@outlook.com
> > wrote:
>
> > Hi guys
> > I was wondering, what actually the reason is that PHP itself does not
> > support multi-threading?
> > I guess this would be realizable, or not? If not, why?
> > Maybe this is a stupid question, but still somehow interesting.
> > Realization in a way as Java does (or just something in that way) would
> > actually be a very nice thing, don't you think?
> > Thank you for your answers :)
> > Florian
> >
>
>
>
>
> --
> Cu respect / Best regards,
> Dipl.-Ing. Ovidiu Farauanu
--- End Message ---
--- Begin Message ---
Ovidiu Farauanu <ovidiugabr...@gmail.com> hat am 31. Oktober 2012 um 09:59
geschrieben:
> Hello Florian,
>
> Usually you want to run a PHP script in two different environments:
> 1. inside a webserver
> 2. in a command line interface
>
> For a web application, the application server does the work for you.
> It is the server job to have a thread pool and balance it correctly.
> So you don't need threads for the same reason threads are prohibited in
> Java EE containers.
> I assume that you don't fork multiple threads for every single HTTP request
> inside a Java Servlet, for instance.
>
> When you are inside a command line usually you start processes instead of
> threads.
> And this is fully supported by PHP.
The drawback of forking is the memory overhead. With every fork you take the
same amount of memory which is not the case if you could use real threads.
> However, there are several reasons in choosing processes instead of threads.
> Several high-level programming languages are starting OS processes for
> language threads.
> But maybe this is not on our topic now.
>
> But I am wondering what do you mean by "multithreading support"?
> Do you need library functions as synchronization primitives?
> Or you are talking about something like "synchronized" keyword?
Since PHP is not threadsafe, it is not possible to run the APACHE in worker
mode, you have to use the prefork model.
--- End Message ---
--- Begin Message ---
Ovidiu Farauanu <ovidiugabr...@gmail.com> hat am 31. Oktober 2012 um 09:59
geschrieben:
> Yes Marco has right.
>
> But more than that, OOP is mainly designed to run in a single threaded
..... I don't put a comment on that.
> environment and it is not the best idea to be used for concurrent
> programming because you will need synchronization everywhere and this slows
> down the code, but also ask for a lot of other troubles.
Well, just avoid the difficulties of creating a good program, because it is too
much efford?
>
> I think functional paradigm is more better suited for concurrent
> programming, and there are some nice features in PHP 5.4
> please see "Closures" and how "callbacks" can be used in PHP. Functional
> features are prepared for Java 8, and they are already in C++11.
What have closures and callbacks to do with concurrent programming?
Nothing. The execution is serialized. There is no parallel in it.
Together with your last message on the list on the same topic, you should
consider reading a bit more on that topic.
--- End Message ---
--- Begin Message ---
"Florian Müller" <florian-muel...@outlook.com> hat am 31. Oktober 2012 um 11:37
geschrieben:
> I actually tought about just the same structures as Java uses(something in
> this way:
> Thread t = new Thread(new Runnable() { public void run() { ...blabla
> }}
> I thought this would actually be a good benefit if PHP supported this. It's
> just as we sometimes use PHP for doing some big Server works (e.g. database
> copying or something) and it would be nice to controll by yourself which
> Thread (or process) does which part of the job.
> For normal HTTP calls which must be handled within milliseconds, this actually
> does not make sense, that's right ;)
Yeah, it does not make sense for the Response script.
But it if PHP would be threadsafe, you would be able to run the Apache in a much
faster and less memory using way.
There once was a configure option in PHP to compile it threadsafe, but they
dropped it for a reason.
And if thinking of PHP as the CGI handler or even as the webserver itself, it
would be great if we could use threads instead of forking processes.
--
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
--- Begin Message ---
Il Wed, 31 Oct 2012 11:57:11 +0100, ma...@behnke.biz ha scritto:
> But it if PHP would be threadsafe, you would be able to run the Apache
> in a much faster and less memory using way.
> There once was a configure option in PHP to compile it threadsafe, but
> they dropped it for a reason.
Because PHP is threadsafe, but a lot of extensions are not.
Besides that, using fpm makes it fast enough.
On Linux a thread is not much faster that a new process, and uses nearly
the same memory, but multiprocessing is much safer than multithreading,
and much simpler to code.
So I don't think that thread safety is such a big deal.
Florian is more interested in the Java abstraction of threading than in
the multithreading itself.
There are various ways to accomplish something similar, but it is not
integrated in the language.
For example, you could use gearman to distribute database-intensive tasks
on a server, or pcntl_fork to parallelize computation.
Bye.
--- End Message ---
--- Begin Message ---
Il Wed, 31 Oct 2012 11:50:00 +0100, ma...@behnke.biz ha scritto:
> The drawback of forking is the memory overhead. With every fork you take
> the same amount of memory which is not the case if you could use real
> threads.
No, it is not.
Forking in Linux uses COW (copy-on-write), so a freshly-forked process
occupies maybe 3-400 bytes of RAM. Only when writing on a memory
location, that location gets allocated.
There are advantages (it is more safe, as you can't overwrite other
processes' memory) and disadvantages (you can't simply read or write
memory to communicate between threads, but must use IPC).
But speed and memory consumptions are not an issue.
Bye.
--- End Message ---
--- Begin Message ---
Hey guys (and/or gals),
I have heard this question entirely too many times, I think at some point
Rasmus just stopped responding to it. The real reason that PHP is not
threaded has nothing to do with PHP internal or extension thread safety,
the reason is more to the extent that it doesn't make sense to add
threading to PHP, it will only increase code and model complexity and
create more points of failure, but again the reason is not this, the reason
is that it doesn't make sense in PHP's native environment to add threading
in the first place. Natively PHP is summoned by a web server, yes you can
call PHP in CLI, but that's not it's point market, PHP is first and
foremost a server-side language for the web and it is ran by a web server
such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but
it could be). All of these web servers (maybe with exception of IIS, i
wouldn't know) work pretty much on the same principal, you have the main
process that spawns a bunch of worker threads (this is adjustable in
configuration, but is typically 1 per cpu thread). These threads are what
actually process the requests and call PHP, meaning that if multiple
threads are processing multiple requests, multiple instances of PHP will be
called. This is why adding threading to PHP makes absolutely no sense, why
would you spawn threads in something that is already being called by a
thread? Don't get me wrong, threads spawning other threads is a solution,
but it is a solution on massively parallel architectures, such as the
GPGPUs that can handle over a thousand threads, and it is a solution for an
entirely different problem, namely costly conditional statements; PHP on
the other hand runs on a general purpose processor that already cache
thrashes and runs into issues with instruction pipelines in parallel
execution, adding more threads to it would do nothing for performance (or
make it worse), make for more complex code and introduce new issues, like
for example how do you test threaded code, debugging, messaging, etc, which
will introduce new places where php apps fail, new security concerns, etc,
and I think we are far from having current issues fixed...
Want to parallelize your PHP execution? Learn to love curl_multi :)
In this case, fix the program, not the programming language. Just my $0.02
-- Alex
--
The trouble with programmers is that you can never tell what a programmer
is doing until it’s too late. ~Seymour Cray
--- End Message ---
--- Begin Message ---
On Wed, Oct 31, 2012 at 6:46 AM, Alex Nikitin <niks...@gmail.com> wrote:
> Hey guys (and/or gals),
>
> I have heard this question entirely too many times, I think at some point
> Rasmus just stopped responding to it. The real reason that PHP is not
> threaded has nothing to do with PHP internal or extension thread safety,
> the reason is more to the extent that it doesn't make sense to add
> threading to PHP, it will only increase code and model complexity and
> create more points of failure, but again the reason is not this, the reason
> is that it doesn't make sense in PHP's native environment to add threading
> in the first place. Natively PHP is summoned by a web server, yes you can
> call PHP in CLI, but that's not it's point market, PHP is first and
> foremost a server-side language for the web and it is ran by a web server
> such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but
> it could be). All of these web servers (maybe with exception of IIS, i
> wouldn't know) work pretty much on the same principal, you have the main
> process that spawns a bunch of worker threads (this is adjustable in
> configuration, but is typically 1 per cpu thread). These threads are what
> actually process the requests and call PHP, meaning that if multiple
> threads are processing multiple requests, multiple instances of PHP will be
> called. This is why adding threading to PHP makes absolutely no sense, why
> would you spawn threads in something that is already being called by a
> thread? Don't get me wrong, threads spawning other threads is a solution,
> but it is a solution on massively parallel architectures, such as the
> GPGPUs that can handle over a thousand threads, and it is a solution for an
> entirely different problem, namely costly conditional statements; PHP on
> the other hand runs on a general purpose processor that already cache
> thrashes and runs into issues with instruction pipelines in parallel
> execution, adding more threads to it would do nothing for performance (or
> make it worse), make for more complex code and introduce new issues, like
> for example how do you test threaded code, debugging, messaging, etc, which
> will introduce new places where php apps fail, new security concerns, etc,
> and I think we are far from having current issues fixed...
That's all understood but there are times when that one request from
the visitor requires many sub-requests like connection to DB and
making SOAP calls. Sure, it can much faster do you think the response
time for the visitor when the sub requests are done in child threads?
Sure, I could implement curl_multi as you state below.
>
> Want to parallelize your PHP execution? Learn to love curl_multi :)
>
> In this case, fix the program, not the programming language. Just my $0.02
>
But how do you then manage those calls or sub-threads? What about
synchronizing? Like you said, fix the program right? Then shouldn't
that be fixed in PHP at the core rather than a hack after?
Cheers,
Tommy
>
> -- Alex
> --
> The trouble with programmers is that you can never tell what a programmer
> is doing until it’s too late. ~Seymour Cray
--- End Message ---
--- Begin Message ---
>
>
> That's all understood but there are times when that one request from
> the visitor requires many sub-requests like connection to DB and
> making SOAP calls.
I would say it's more than just "there are times", that's how a typical
script lives, it imports libraries, queries the database, and talks to
other systems.
> Sure, it can much faster do you think the response
> time for the visitor when the sub requests are done in child threads?
>
I am not so sure of that. Let's make it a mental exercise really quickly.
So let's say we have a website, lets say that we want to query the database
and make 2 soap calls at the same time, so for every request we spawn 3
threads to do this. Now, ofcourse for every single request, if they were
not concurrent, we would run faster, but what happens when we add a little
load to this, say 300 requests per second (and i have built wordpress
instances that do 360 on a small ec2 instance). You have say 4 cores @ 1
thread/core, so your web server has 4 threads that are continuously running
+ 1 for dispatch, and then you have 900 threads that you now have to spawn,
process, transfer execution to other threads (context switch in and out,
maybe a few time) and terminate per second. The problem is that modern CPUs
are not very good at doing this, you are context switching between threads,
you are context switching between cores, because your network stack runs on
a different core or for any other reason, etc, which is very expensive
computationally, on top of which you have to spawn new threads and then
kill them. And on a say 4 requests per second system, you may win a few
miliseconds on parallelizing your data aggregation, but any real load will
see that benefit turn in a negative direction.
Curl multi is not necessarily a hack, in context of soap, i can build my
soap queries, which is always a serial process anyways, and then use curl
multi to run the soap requests in parallel, so there, one part already
solved.
Database is even easier, since you are usually using a persistent
connection, you are already relying on the mysql driver to thread your
calls while maintaining a single instance of your connection (eliminating
the need for three way hand shakes every time you want to talk to your
database, which saves you at least 3 round trips, plus auth (which is 3
more round trips and crypto on both sides)), so even there this problem is
already solved for you. And if you are saying that you can run multiple
parallel queries for the same PHP process, you really need to fix your
database and queries first :)
Then shouldn't that be fixed in PHP at the core rather than a hack after?
Nope, no need to needlessly complicate PHP especially if there is no need
or performance gain in doing it. There are plenty of other areas where PHP
can be fixed where it does matter, i mean have a look at a month of PHP
bugs if you want to get depressed :)
--
The trouble with programmers is that you can never tell what a programmer
is doing until it’s too late. ~Seymour Cray
--- End Message ---
--- Begin Message ---
Johannes Reichardt <johannes.reicha...@googlemail.com> hat am 30. Oktober 2012
um 16:37 geschrieben:
> > In times of testability and several design patters, the use of static calls
> > is
> > really outdated.
> > I understand that you can read and write the invocations of the methods much
> > faster, but you should think more to the future on that point.
> I am not sure if that is true for TURBOPY. It has been "organically
> grown" over the years
> and I had no scenario where I needed instances. The benefit of more
> compact code is worth
> it for this scenario I think. The nature of a server request is still
> very procedural.
Yeah, but when thinking of your TURBOPY as an application, you will come to a
point where changes are neccessary,
They stopped programming procedural PHP for a reason. And they introduced things
like DIC for a reason.
If you want to make sure that your framework works even after changing or adding
somethink, you have to think about phpunit for example.
And if you think about add-ons or mods to your basic classes, you will consider
design patterns that are incompatible with static usage.
If your code will run a longer living CGI process for example, then you will
have to take care that all static members are resetted, otherwise the next user
gets them. That's where objects kick in.
think about it, if you want to make TURBOPY ready for the future.
--
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
