Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor [RSS Feed]

#1 Jan. 19, 2011 15:43:18

Martin S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


I think the point is that the php language itself does not provide solid
construct for writing rock-solid code. Yes, there are many
programmers/hackers that can, but the effort they put is huge.

it's so easy to break well-written bug-free code, that's impossible for
developers to share libraries, and even those who share has the problems
that the language does not provides the language construct for the system to
evolve without breaking its clients code.

As you were speaking about Java, we must learn from Java experience. All
that non-sense stuff that it imposes is the same stuff that provide to Java
developers to share their libraries. All you need to do is put the .jar in
your classpath, and that's it.

In Java you are free to extend a class --yours or imported-- without worries
about it's internal implementation. Is that possible in PHP? nope.
__construct breaks that.

So instead of hacking the language, why don't we start by adding better
language constructs.
Look at the foreach statement and the Iterators, that is a really good
example of a well-designed language construct.

I'm really interested on threads for PHP, but as a language construct.
Threads are not easy, even the most experienced programmer could not get it
right from the scratch.

IMHO, as a simple PHP programmer, the language should provide the simplest
language construct and the engine should handle all the complexity under the
hood.

Martin Scotta


On Wed, Jan 19, 2011 at 8:40 AM, Sam Vilain <sam.vil***@*penparallel.com>wrote:

> On 19/01/11 16:14, Sam Vilain wrote:
> > In general, Java's basic types typically correspond with types that can
> > be dealt with atomically by processors, or are small enough to be passed
> > by value. This already makes things a lot easier.
> >
> > I've had another reason for the differences explained to me. I'm not
> > sure I understand it fully enough to be able to re-explain it, but I'll
> > try anyway. As I grasped the concept, the key to making VMs fully
> > threadable with shared state, is to first allow reference addresses to
> > change, such as via generational garbage collection. This allows you to
> > have much clearer "stack frames", perhaps even really stored on the
> > thread-local/C stack, as opposed to most dynamic language interpreters
> > which barely use the C stack at all. Then, when the long-lived objects
> > are discovered at scope exit time they can be safely moved into the next
> > memory pool, as well as letting access to "old" objects be locked (or
> > copied, in the case of Software Transactional Memory). Access to
> > objects in your own frame can therefore be fast, and the number of locks
> > that have to be held reduced.
>
> Ref:
>
>http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#33308> and to a lesser extent, the note on
>
>http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.html#22244>
> > Perhaps to support/refute this argument, in your JVM, how do you handle:
> >
> > - memory allocation: object references' timeline and garbage collection
> > - call stack frames and/or return continuations - the C stack or the
> heap?
> > - atomicity of functions (that's the "synchronized" keyword?)
> > - timely object destruction
> >
> > put it forward that the overall design of the interpreter, and
> > therefore what is possible in terms of threading, is highly influenced
> > by these factors.
> >
> > When threading in C or C++ for instance (and this includes HipHop-TBB),
> > the call stack frame is on the C stack, so shared state is possible so
> > long as you pass heap pointers around and synchronise appropriately.
> > The "virtual" machine is of a different nature, and it can work. For
> > JVMs, as far as I know references are temporary and again the nature of
> > the execution environment is different.
> >
> > For VMs where there is basically nothing on the stack, and everything on
> > the heap, it becomes a lot harder. To talk about a VM I know better,
> > Perl has about 6 internal stacks all represented on the heap; a function
> > call/return stack, a lexical scope stack to represent what is in scope,
> > a variable stack (the "tmps" stack) for variables declared in those
> > scopes and for timely destruction, a stack to implement local($var)
> > called the "save" stack, a "mark" stack used for garbage collection, ok
> > well only 5 but I think you get my point. From my reading of the PHP
> > internals so far there are similar set there too, so comparisons are
> > quite likely to be instructive. It's a bit hard figuring out everything
> > that is going on internally (all these internal void* types don't help
> > either), and whether or not there is some inherent property of reference
> > counting, or whether it just makes a shared state model harder, is a
> > question I'm not sure is easy to answer
> >
>
> Based onhttps://github.com/smarr/RoarVM/blob/98caf11d0/README.rstit
> can be seen that indeed it is a completely different architecture. From
> the first of the ACM papers' abstract:
>
> In addition to the cost of inter-core communication, two hardware
> characteristics influenced our design: the absence of hardware-provided
> cache-coherence, and the inability to move a single object from one
> core's cache to another's without changing its address.
>
> > In any case, full shared state is not required for a large set of useful
> > parallelism APIs, and in fact contains a number of pitfalls which are
> > difficult to explain, debug and fix. I'm far more interested in simple
> > acceleration of tight loops - to make use of otherwise idle CPU cores
> > (perhaps virtual as in hyperthreading) to increase throughput - and APIs
> > like "map" express this well. The idea is that the executor can start
> > up with no variables in scope, though hopefully shared code segments,
> > call some function on the data it is passed in, and pass the answers
> > back to the main thread and then set about cleaning itself up.
>
> You could probably support this with any paper on Erlang ;-)
>
> Sam
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
>

Offline

#2 Jan. 19, 2011 15:51:40

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


hi,

On Wed, Jan 19, 2011 at 4:41 PM, Martin Scotta <martinsco***@*mail.com> wrote:
> I think the point is that the php language itself does not provide solid
> construct for writing rock-solid code. Yes, there are many
> programmers/hackers that can, but the effort they put is huge.

Care to enlighten me and tell me what is missing to allow one to write
rock-solid code?

> it's so easy to break well-written bug-free code, that's impossible for
> developers to share libraries, and even those who share has the problems
> that the language does not provides the language construct for the system to
> evolve without breaking its clients code.

I think that most of PHP is actually thread safe. And almost all
libraries are now either thread safe or used in a way that makes them
thread safe.

Now, about making the engine itself and the userland scripts able to
implement parallelized functions for multi-core architecture (which is
very disputable in a web environment, btw), that's a totally different
topic and I don't think it is worth the effort.


> I'm really interested on threads for PHP, but as a language construct.
> Threads are not easy, even the most experienced programmer could not get it
> right from the scratch.

Most of the time what PHP needs are non blocking operations, not
necessary multi threaded operations. That's what some of the newly
implemented features do (like in mysqlnd, to fetch the data).

> IMHO, as a simple PHP programmer, the language should provide the simplest
> language construct and the engine should handle all the complexity under the
> hood.

Honestly if a given part of an application needs something along this
line for performance reasons, then doing that on the same box where
the request is executed may be a bad idea. Tools like gearman will do
a far better jobs and will let you do resource intensive processing on
other machines where cores may not be already busy serving other
requests.

my 2 cents based on my experiences and benches in this area,

Cheers,
--
Pierre

@pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Jan. 19, 2011 17:15:13

Rasmus L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


On 1/19/11 7:50 AM, Pierre Joye wrote:
> Honestly if a given part of an application needs something along this
> line for performance reasons, then doing that on the same box where
> the request is executed may be a bad idea. Tools like gearman will do
> a far better jobs and will let you do resource intensive processing on
> other machines where cores may not be already busy serving other
> requests.
>
> my 2 cents based on my experiences and benches in this area,

In real-world situations this is what I see as well. People either want
to parallelize operations like fetching data from multiple URLs at once,
where they think they need threading, but actually just need to learn
the async calls, or they want to background something that takes a while
to finish. This second case is much better handled by a separate job
manager like Gearman.

One example I have written is a rule engine that calculates a trust
score for a financial transaction. The rules can get a bit complicated
so it isn't something I want to have the web request wait on. Using the
Kohana framework the call to kick off the rule engine looks like this:

Gearman::doBackground('kohana', "gearman/payment_score/{$payment->id}")

And I have a 'kohana' gearman worker that loads the entire framework
which means my actual worker code is just another controller that looks
exactly like my Web code. Any controller can be backgrounded that way
with the added advantage that I can distribute these backgrounded jobs
to a pool of worker servers that are separate from my frontend web
servers, but they all run the same code stack. To me this is a much
more flexible way to solve the problem that having to write
thread-management code in my Web code and have my already overloaded web
servers take on more work.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Jan. 19, 2011 19:59:24

Stas M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


Hi!I think the point is that the php language itself does not provide solid
construct for writing rock-solid code. Yes, there are many
programmers/hackers that can, but the effort they put is huge.I think this is completely untrue.In Java you are free to extend a class --yours or imported-- without worries
about it's internal implementation. Is that possible in PHP? nope.
__construct breaks that.Could you please explain what you mean? How __construct breaks extendinga class?IMHO, as a simple PHP programmer, the language should provide the simplest
language construct and the engine should handle all the complexity under the
hood.I see no way of hiding threads complexity "under the hood" - if you wantthreads, you'll need to deal with synchronization, locking, raceconditions, etc. Do you see any way to avoid it?--
Stanislav Malyshev, Software Architect
SugarCRM:http://www.sugarcrm.com/(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Jan. 20, 2011 00:07:04

Martin S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


Many PHP features should be language constructs, but they were made as
language hacks.

__construct is evil, as like any other language hack

It does not provides a safe fundation to build safe abstractions, reusable
and extendibles components, which leads to the lack of PHP libraries.

Let's suppose there is a library that provides an utility class, which has
no super class nor constructor.

// lives in library.phar
class Utility { }

A client uses this class by extending it

// includes library.phar
class Client extends Utility {
function __construct() {
// client initialization code here
}
}

At that point the Utility class can not add __construct safely, and if it
does Client will break it, it's not calling the constructor.

but what happen if Utility provides a __constructor
class Utility {
function __construct() {
// Utility initialization here
}
}

class Client {
function __construct() {
// some code
parent::__construct(); // as good client call the super class
// and then more code
}
}

In this case the Utility is forced to keep the __construct, if it's removed
the Client call will fail as parent::__construct will not exists.

In both cases there were no API changes, only the way the objects are
initializated was what changed.

My point is that the language does not provide solid fundations (aka
language constructs) for systems and libraries to evolve in a safe way.

Martin Scotta


On Wed, Jan 19, 2011 at 4:58 PM, Stas Malyshev <smalys***@*ugarcrm.com>wrote:

> Hi!
>
>
> I think the point is that the php language itself does not provide solid
>> construct for writing rock-solid code. Yes, there are many
>> programmers/hackers that can, but the effort they put is huge.
>>
>
> I think this is completely untrue.
>
>
> In Java you are free to extend a class --yours or imported-- without
>> worries
>> about it's internal implementation. Is that possible in PHP? nope.
>> __construct breaks that.
>>
>
> Could you please explain what you mean? How __construct breaks extending a
> class?
>
>
> IMHO, as a simple PHP programmer, the language should provide the simplest
>> language construct and the engine should handle all the complexity under
>> the
>> hood.
>>
>
> I see no way of hiding threads complexity "under the hood" - if you want
> threads, you'll need to deal with synchronization, locking, race conditions,
> etc. Do you see any way to avoid it?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM:http://www.sugarcrm.com/> (408)454-6900 ext. 227
>

Offline

#6 Jan. 20, 2011 00:20:28

Stas M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


Hi!Many PHP features should be language constructs, but they were made as
language hacks.

__construct is evil, as like any other language hackConstructors are standard feature in many languages. There's nothingevil in them.class Client {
function __construct() {
// some code
parent::__construct(); // as good client call the super class
// and then more code
}
}Arguably, initialization is the part of the API, but I see your point -it might be useful to supply all objects with empty default ctor so thatparent::__construct() always works. Submit a feature request tobugs.php.net.--
Stanislav Malyshev, Software Architect
SugarCRM:http://www.sugarcrm.com/(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Jan. 20, 2011 14:26:30

Martin S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


Martin Scotta


On Wed, Jan 19, 2011 at 9:19 PM, Stas Malyshev <smalys***@*ugarcrm.com>wrote:

> Hi!
>
>
> Many PHP features should be language constructs, but they were made as
>> language hacks.
>>
>> __construct is evil, as like any other language hack
>>
>
> Constructors are standard feature in many languages. There's nothing evil
> in them.
>
>
> class Client {
>> function __construct() {
>> // some code
>> parent::__construct(); // as good client call the super class
>> // and then more code
>> }
>> }
>>
>
> Arguably, initialization is the part of the API, but I see your point - it
> might be useful to supply all objects with empty default ctor so that
> parent::__construct() always works. Submit a feature request to
> bugs.php.net.
>
>
and what what happen if the extending class does not call
parent::__construct() ?
__construct is just like any other function, but with semantic added on top
of.

Changing the way it behaves will cause many headaches

---
BTW, Did you noted that "self" keyword is allowed as method name? so I
belive it is not a keyword at all

class Foo{
function self() {
echo __METHOD__, PHP_EOL;
}
}

$foo = new Foo();
$foo->self();


> --
> Stanislav Malyshev, Software Architect
> SugarCRM:http://www.sugarcrm.com/> (408)454-6900 ext. 227
>

Offline

#8 Jan. 21, 2011 04:48:53

David M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


On 20/01/11 23:25, Martin Scotta wrote:and what what happen if the extending class does not call
parent::__construct() ?
__construct is just like any other function, but with semantic added on top
of.

Changing the way it behaves will cause many headaches

---
BTW, Did you noted that "self" keyword is allowed as method name? so I
belive it is not a keyword at all

class Foo{
function self() {
echo __METHOD__, PHP_EOL;
}
}

$foo = new Foo();
$foo->self();'self' is not a keyword, but a special predefined class:http://www.php.net/manual/en/reserved.classes.php'parent' also works as a method name for the same reason.
'static' does not work, as it's a keyword.

Cheers,
David

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Jan. 21, 2011 10:17:34

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor


On Thu, Jan 20, 2011 at 3:25 PM, Martin Scotta <martinsco***@*mail.com> wrote:

> and what what happen if the extending class does not call
> parent::__construct() ?
> __construct is just like any other function, but with semantic added on top
> of.
>
> Changing the way it behaves will cause many headaches

What does that have to do with the topic of this thread? Also the
__construct behavior and how/why one should call the parent
__construct is also well documented. Anyway, that does not prevent
anyone to write rock solid code.


Cheers,
--
Pierre

@pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] [citations for] Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support