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...@openparallel.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 on https://github.com/smarr/RoarVM/blob/98caf11d0/README.rst it > 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 > >
