[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-general
Subject:    Re: [PHP] Re: Multithreading for OOP PHP
From:       Dotan Cohen <dotancohen () gmail ! com>
Date:       2012-11-03 15:47:24
Message-ID: CAKDXFkPjPPr86eTr2B225H8sLVNhNq24PASK0xBzT7N0mUSbnw () mail ! gmail ! com
[Download RAW message or body]

> As far as php side goes, it's a
> problem of design of the apps. Just because people decided to go through
> hoops to use the threaded model doesn't mean that it is any faster than
> writing to the same thing in event driven model, event driven way is
> sometimes much faster than threads.

I'm on both sides of the fence on this one. Imagine the database
operation (not necessarily a SELECT statement) that could take an
arbitrarily long time to complete. PHP should be able to hand that off
to another thread and be done with it:
$dbOpertation = dbThread($sql)
$dbOpertation->start();

Currently, we've got to to write an alternative file dbOperation.php
and call it via exec(), complete with shell-escaping arguments and all
the dangers that go with that:
exec('dbOperation.php'.escapeshellarg($sql));

Now who knows what escapeshellarg() will do to my precious
hand-crafted SQL so I'll have to debug and test that as well. Wait
until you see what that does to your single quotes, and you are in a
world of hurt if your SQL contains literals that also happen to
contain escaped quotes. I don't even know what other characters
escapeshellarg() will mungle, it is not mentioned in the fine manual
so I can either go read the source or start experimenting. And I
happen to be a hobbiest sysadmin, what happens to the poor PHP dev who
doesn't even quite understand the shell or think to escape the
arguments. The prevalence of PDO for simple queries even further
removes many (novice) PHP devs from thoughts of escaping


> Don't blame the language, blame the
> poor dev who made it harder on themselves... There are plenty of big and
> well performing systems online that pull data from many a locations on the
> back end and still manage to serve it to you in less than 2 hundredth of a
> second without the need for threading server side code. That's because they
> are designed well and implemented well as a system.

That is either naive or trolling. You either know very well that some
database operation cannot be completed in n/100 of a second, and we
haven't even started to talk about curl or other potentially
long-running operations.


> Finally another thing to consider is how the operating systems deal with
> high amounts of threads, how different architectures deal with them, while
> Linux is pretty good about threads, other systems have significant
> problems. Php is meant to run on all of them so you choose the model that
> works for all.

I see. Due to a Windows deficiency my PHP-on-*Nix code should suffer.
Are you not aware that some PHP features are available on some OS but
not others? Or that function differently by OS? Seriously, it looks
like you are trolling.


> Lastly I am sorry, but massively parallel architecture for general
> computing is still about 10 years out. That's where parallel processing
> design will be bore efficient and beneficial. When we have that, and
> programmers learn massively parallel design, maybe then we will have a need
> for parallel php (pphp?) for now, there is no need, only poor design.

What? i don't know what you mean by "massively parallel architecture"
but it certainly has no relevancy to the PHP dev who wants to run a
long SQL query.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]