Prev: Filtering all output to STDERR
Next: constants STDOUT, STDERR, STDIN not working in 5.2.x?
From: Teus Benschop on 23 Mar 2010 00:23
There can be, and there are, differences between the languages. There
are so many languages out there, and it works like a market place. If
you like the language, use it. It it fails to do what you want, you
switch to another one. There is no need to beg the php developers to
implement anything, as long as you can switch to another language. Teus.
From: Larry Garfield on 23 Mar 2010 01:01
On Monday 22 March 2010 10:51:14 pm Tommy Pham wrote:
> Threading is one of the 2 two main reasons why I moved to Java &
> asp.net (C#). I've built a PHP based web crawler about 10 years ago.
> I ran into some problems: cookies, form handling and submission,
> threading, and application variables. I later found some solutions
> for cookies, form handling & submission. But no solution for
> threading and application variables. Thus the move. Here's a simple
> example of one of the many uses for threading. For an e-commerce
> site, when the shopper requests for a category (ID), you can have a
> thread to get all subcategories for that category, another thread to
> get any assigned products, another thread to fetch all manufacturers
> listed under that category, another thread to fetch any filters (price
> ranges, features, specs, etc) set by the store owner that would fall
> under that category, etc... versus what PHP currently doing now:
> fetch subcategories, then fetch assigned products, then fetch
> manufacturers, etc.... Performance would increase ten fold because of
> parallel (threading) operations versus serial operations. Add that to
> application variable (less memory usage and CPU cycles due to
> creating/GC of variables that could be used for an entire application
> regardless of requests & sessions), you have an excellent tool.
>
> Regards,
> Tommy

Threading is also much more difficult to program for safely, because thread
order is non-deterministic. Do you really want to unleash hoards of
marginally competent programmers on a threaded enviornment? :-)

Also, the architecture you describe above is fine if you're scaling a single
server really big. PHP is designed to scale the other direction: Just add
more servers. There's no data shared from one request to another, so there's
no need to share data between web heads. Throw a load balancer in front of it
and spin up as many web servers as you need.

The "shared nothing" design is very deliberate. It has design trade-offs like
anything else.

PHP is a web-centric language. It's not really intended for building tier-1
daemon processes, just like you'd be an idiot to try and code your entire web
app in C from the start.

--Larry Garfield
From: Jochem Maas on 23 Mar 2010 01:39
Op 3/23/10 12:02 AM, Daevid Vincent schreef:
> I've been using PHP for a decade or so (since PHP/FI) and love it. The one

<snip />

well they certainly ripped you a new one didn't they :)

why no threads? shared-nothing architecture, that's very deliberate, it has draw
backs as well as advantages, either way you have to understand the reasoning and
how to leverage it. shared-nothing obviously doesn't lend itself to writing fast
daemonized code, then again it wasn't meant to.

I'd say that named function/method parameters would be a nice addition though -
although having said that a decent IDE with code completion (DocBlocks) and well commented,
well structured code mitigate the issue, for me anyway.

>
>

From: Rene Veerman on 23 Mar 2010 02:26
ExecSum:
* +1 for better threading features in PHP.
* overloading = inheritance?
* listreaders plz allow ppl to vent some frustration without
starting a flamewar.

Threading can be implemented in PHP with an
fopen('http://yourserver.com/url')->fread()_all_threads+usleep(50ms)->fclose()+process
loop.

My own newsscraper threads well like this.
The central script figures out what sites to scrape, and the treaded
subsystem makes sure 1 page per site per N seconds is retrieved.

But i've yet to find a way to keep global objects in memory between
http requests, outside $_SESSION, which i believe is just stored to-
and loaded from disk between http requests.

However, now that i think of it, you could have large pieces of
software stay in memory in a single php script that runs forever and
reads commands (as arrays) out of files (on memory disk?) (put there
by "thread-scripts") and [the "forever running script"] outputs to
stdout, which is caught by the thread-scripts, then passed back to the
thread-caller via fread().
I usually use json for such constructs.
But it's a total hack of course, and i have no idea about performance
issues or even timing bugs. it's "theoretically possible"..

>there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java

well you could shove all the params in an array, then shove that to
the function called, _or_ a preparatory function that calls the old
function.

as for overloading functions, i think with a bit of cleverness you can
come up with a class / set of functions that simulate overloading of
functions and even inheritance. i for a fact simulate polymorphism
with $functionName_fromPluginX ($params).
i smell all the ingredients that would allow you to overload functions
in php aswell. you'd just have to call things a bit differently,
perhaps like
$var = $overloadingManager->call ('functionName',
'context(object-instance-id)', $param1, $param2).

Better yet; aren't OOP's (and php5's) inheritance features (for
classes) similar to functions overloading? k, it forces you to group
such functions into an object, and derivations into subobjects, but
that's not a show-stopper at all.. You can always ignore the object
boundary and have 1 object-tree for all functions that require
overloading.


& lastly, about the politics of this mail-thread;
imo, it's the ones who "open the counterattack" who start the
flamewar, out of something that is clearly in this case just venting
some frustration with at least partially valid reasons..

imo, it would be wiser to have offered the guy some actual tips and/or
a casual "hey, you could've phrased it friendlier, given the fact that
php costs nothing and all, dude", rather than grabbing the
flamethrower and setting it to vaporize.

On Tue, Mar 23, 2010 at 1:02 AM, Daevid Vincent <daevid(a)daevid.com> wrote:
> I've been using PHP for a decade or so (since PHP/FI) and love it. The one
> problem that seems to always keep coming back on enterprise level projects
> is the lack of threading. This always means we have to write some back-end
> code in Ruby or Java or C/C++ and some hacky database layer or DBUS or
> something to communicate with PHP.
>
> Will PHP ever have proper threading? It would sure let the language take
> the next logical leap to writing applications and daemons. I love the idea
> that Rails/Ruby have where you can just load objects in memory once and
> keep using them from page to page (this is NOT the same as a $_SESSION,
> it's way more flexible and powerful).
>
> But more importantly, in one application I'm working on, we need to connect
> to an Asterisk system for the IVR abilities. This means we have Ruby doing
> all that fun stuff and PHP doing the web stuff, but we're also duplicating
> a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's
> calling in, advertisements served, products shown, etc. We could have used
> Rails for the web portion, but I want to stay with PHP and I'm sure I don't
> have to explain to you PHPers why that is. Without threads, PHP just isn't
> even an option or only one user would be able to call in at a time.
>
> The pcntl stuff is not feasible. It's a hack at best. Spawning multiple
> scripts is also a recipie for disaster.
>
> When will the PHP core-devs (Zend?) realize that PHP is much more than a
> hook to a database. It's much more than web pages.
>
> Is this a case of "it's too hard"? Or is it a case of PHP core developers
> just being douche-bags like they are about the whole
> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java or
> other typed languages)
>
> As usual, I created a poll here too:
> http://www.rapidpoll.net/awp1ocy
>
> Past polls are below:
> http://www.rapidpoll.net/8opnt1e
> http://www.rapidpoll.net/arc1opy (although someone hacked this poll and
> loaded up the 76 votes like a little cheater)
>
From: Tommy Pham on 23 Mar 2010 03:35
On Mon, Mar 22, 2010 at 10:01 PM, Larry Garfield <larry(a)garfieldtech.com> wrote:
> On Monday 22 March 2010 10:51:14 pm Tommy Pham wrote:
>> Threading is one of the 2 two main reasons why I moved to Java &
>> asp.net (C#).  I've built a PHP based web crawler about 10 years ago.
>> I ran into some problems: cookies, form handling and submission,
>> threading, and application variables.  I later found some solutions
>> for cookies, form handling & submission.  But no solution for
>> threading and application variables.  Thus the move.  Here's a simple
>> example of one of the many uses for threading.  For an e-commerce
>> site,  when the shopper requests for a category (ID), you can have a
>> thread to get all subcategories for that category, another thread to
>> get any assigned products,  another thread to fetch all manufacturers
>> listed under that category, another thread to fetch any filters (price
>> ranges, features, specs, etc) set by the store owner that would fall
>> under that category, etc...  versus what PHP currently doing now:
>> fetch subcategories, then fetch assigned products, then fetch
>> manufacturers, etc....  Performance would increase ten fold because of
>> parallel (threading) operations versus serial operations.  Add that to
>> application variable (less memory usage and CPU cycles due to
>> creating/GC of variables that could be used for an entire application
>> regardless of requests & sessions), you have an excellent tool.
>>
>> Regards,
>> Tommy
>
> Threading is also much more difficult to program for safely, because thread
> order is non-deterministic.  Do you really want to unleash hoards of
> marginally competent programmers on a threaded enviornment? :-)

Marginally competent? I think some, if not many, on this list will
disagree with that ;)

>
> Also, the architecture you describe above is fine if you're scaling a single
> server really big.  PHP is designed to scale the other direction: Just add
> more servers.  There's no data shared from one request to another, so there's
> no need to share data between web heads.  Throw a load balancer in front of it
> and spin up as many web servers as you need.

Load balancer is used when the server is overloaded with requests and
upgrade has reached it's limit. That's not the same thing as a simple
request where multiple answers are needed as in my example. If you're
thinking of implementing something like my example across multiple
servers (where each server will fetch an answer for a simple request)
via another method, then you're going to face similar issues as
threading ie session/request sync which is equivalent to thread
safety/sync/deadlock but now it's worse because it's spread across
network where performance issues comes in because internal system IO >
(network IO + internal system IO).

>
> The "shared nothing" design is very deliberate.  It has design trade-offs like
> anything else.
>
> PHP is a web-centric language.  It's not really intended for building tier-1
> daemon processes, just like you'd be an idiot to try and code your entire web
> app in C from the start.

Of course since C was engineered to create OSes and (text based) apps
when SMP/MC is unheard of. But we're now in the digital era where
SMP/MC is very common place. In fact, trying to buy a new
desktop/laptop now without a multicore becomes very difficult and
undesired. Why not make use of the SMP/MC? :) PHP seems strive and
somewhat 'imitate' languages like java & asp.net. Not trying to go
off topice but for example: namespace (namespace in asp.net and
packages in java). For many of us that don't use namespace now or
even when it's not yet implemented, we (PHP web app dev) already
implement our own version of it - subfolders. So why not copy or
imitate the features that would be more beneficial if not more
usability ie threading? PHP is already ahead of java & asp.net in
terms of generics, not strong typed.

Regards,
Tommy

>
> --Larry Garfield
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Filtering all output to STDERR
Next: constants STDOUT, STDERR, STDIN not working in 5.2.x?