hmm, maybe the Zend engine doesn't support this, but couldn't you try at least to overload (or whatever) the access and modification of static variables.

What also crashes is trying to store a reference to an object in a normal class variable. Aren't you able to make a copy of the variables and synchronize on modifciation? I think only with an extended support of sharing variables, there will be a visible gain with pthreads.

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Access to static variables cannot be reasonably made thread safe. The solution 
is; the array you wish to share should be abstracted as an object that extends 
Stackable, this object can be passed around between threads and will work as 
expected.

Statics are destined for complete removal I think, I wanted them to be readable, 
and they should be, but people expect them to work in impossible ways. It would 
of course be possible, but not reasonably, it will be no good for pthreads to 
make it work, so avoid them completely.

Stackable/Thread/Worker are all objects prepared to work in a multi-threaded 
environment, if you wish to share an array, or object, or data that isn't a 
simple type, then abstract the data in one of the threaded objects and pass a 
reference to that around.

Passing variables by reference is unsupported due to the storage methods that 
pthreads uses to share data among contexts - which is serialization, the well 
tested and reliable way of sharing data among contexts. Any data that is not a 
simple type will be serialized, thereby making references pointless.

<?php
class MySharedData extends Stackable {
  public function __construct($initial) {
    $this->data = $initial;
  }
  /** merging will work [] may not **/
  public function append($data){
    $this->data = array_merge($this->data, array($data));
  }
  public function fetch(){
    return $this->data;
  }
  public function run(){
    /* you must declare a runnable method for threaded objects */
    /* this may not make sense to you right now, but it will be the case that
       these objects are actually runnable and do need to be executed, for 
instance
       in this example you might want to dump that shared data to a database */
  }
}

class MyThread extends Thread {
  public function __construct($data) {
    $this->data = $data;
  }
  public function run(){
    $this->data->append(array($this->getThreadId() => __CLASS__));
  }
}

$data = new MySharedData($_SERVER["argv"]);
$threads = array();

for(;$i<4;$i++) {
        $threads[$i]=new MyThread($data);
        $threads[$i]->start();
}

foreach($threads as $thread)
        $thread->join();

print_r($data->fetch());
?>

Thank you, but then at least disable the static access in threads. Segmentation faults are not beautiful ;)

Why does this need so complicated... but I think I can work with this. Better than nothing. A question: why do you need to serialize and cannot simply copy the zvals, zend_classes etc? (and update the pointers)

Could you please provide in documentation a few more examples for certain situations? Otherwise users won't have a real idea how to use these classes and variables.

I will of course give the documentation the once over, it was changing very 
quickly while developing pthreads and so feels a bit incomplete. I will leave 
this bug open until I have found the time to update the documentation with some 
examples. 

There are examples provided with pthreads and available on git that cover in 
great detail many of the features of pthreads and how to do things and how not 
to do things. Additionally on the index of http://pthreads.org is a rundown of 
"how this works", which should give you a good basis for understanding all the 
examples. The text on the index was destined for the introduction in the manual, 
and still is.

Some walls are not worth jumping over, because the builder has put broken glass 
in cement on the top, just out of site.

What we are doing here is jumping over the necessary walls and avoiding the ones 
with the glass. We are not executing in C, we are executing in Zend, which is an 
architecture designed not to share anything, it forms the basis of the thread 
safety we manipulate in order to execute our threads. The only way to exist is 
co-exist, the defined, reliable and real world tested way of sharing data among 
contexts is serialization, and so that is what we do because almost all of PHP 
supports serialization it's the safest, most compatible, and importantly most 
forward compatible way of sharing data. Objects included with pthreads avoid it 
where they can, basic types are stored in their true form. At the object level, 
most things work as expected, I think the only exception being [] on account of 
the zend engine expecting a pointer that we cannot reasonably provide. Static 
variables are not at the object level, the engine does not permit you the same 
control over these variables.

I'll say it again; the only way to exist is co-exist. If PHP has a solution to a 
problem then absolutely we should use it - as it's been tested for millions of 
hours by hundreds of thousands of people. Where PHP doesn't provide, pthreads 
will attempt too, when it can be considered safe, and compatible.

There will always be limitations, but I should hope they are limitations that 
you can reasonably work around, safely.

On serialization: you asked why we cannot copy the zend_class's and zvals. 
Infact, this is what we do actually do.

Serialization achieves a safe copy of the data, on normal objects this can incur 
overhead, but it's acceptable overhead because it provides safety, and 
compatibility. 
Threaded objects do not require serialization, they manipulate the serialization 
interface to pass around the address of the original object because it's 
handlers can be executed from anywhere by any context, these objects are 
prepared and should always be used over any type that you wish to have as a 
member. 
To force this, to redeclare every boolean/string/array/long as a threaded object 
for the user would incur unacceptable overhead and additionally all but an array 
and object are stored in their true form and wouldn't incur any overhead from 
serialization anyway.
Once all of this is documented you will make the right choices, pthreads does 
actually provide almost all you need, but it may not be where or how you expect 
it, for very good reason.

I can understand which overhead this would be. But maybe you could introduce a new keyword like "synchronized" before (static) variables that are then accessible via the global keyword or a normal static call in a thread (=> redeclaration of the few variables)?

The examples at github are helpful, but I think they remain unnoticed for most users...

It would be to no end, I cannot actually synchronize access even if I could 
introduce the keyword ( which I cannot, from an extension ). When PHP code reads 
a static variable no handlers are invoked, handlers are for the object level and 
static variables are not at the object level.

The only way to achieve useable static members would be to re-declare for the 
user anything declared as static as a threaded object and this is not a 
reasonable solution to the problem because it would incur, for every entry in 
every thread, weather they use statics or not, unacceptable overhead and 
instructions that can be avoided.

Your test with the constants does also not work (tests/global-constants.diff):

001+ Notice: Use of undefined constant SCONST - assumed 'SCONST' in /private/var/root/pthreads/tests/global-constants.php on line 11
002+ 
003+ Notice: Use of undefined constant LCONST - assumed 'LCONST' in /private/var/root/pthreads/tests/global-constants.php on line 12
004+ 
005+ Notice: Use of undefined constant DCONST - assumed 'DCONST' in /private/var/root/pthreads/tests/global-constants.php on line 13
001- string:string(8) "mystring"
002- long:int(10)
003- double:float(1.19)
004- null:NULL
005- boolean:bool(true)
006+ 
007+ Notice: Use of undefined constant NCONST - assumed 'NCONST' in /private/var/root/pthreads/tests/global-constants.php on line 14
008+ 
009+ Notice: Use of undefined constant BCONST - assumed 'BCONST' in /private/var/root/pthreads/tests/global-constants.php on line 16
010+ string:string(6) "SCONST"
011+ long:string(6) "LCONST"
012+ double:string(6) "DCONST"
013+ null:string(6) "NCONST"
014+ boolean:string(6) "BCONST"

I know, you cannot serialize ressources. But is there no way to share a socket-ressource (over the Stackable object)? I want to listen in one thread in an continuing loop and pushing sometimes from the mainthread some messages over the socket. Also I would prefer not to have to duplicate a mysql-ressource (which is less problematic). But only one socket can listen and send on the same port, so I cannot open in mainthread and in the listening thread a socket. Yes, surely, I could use shmop (shared memory), but this is slow, I feel. Is there an alternative?

Other problem is when instantiating extended classes. I cannot call the __construct-function of the parent class, because the static access with parent::__construct fails.

the constants bug I have fixed in git.

Both parent:: and self:: appear to suffer from the same bugs, noted...

It would be better if you opened new bugs rather than adding to this one.

Resources are explained in the introduction text on pthreads.org.

Ok, next time I will split up into different bug reports.

I read that your page, but doesn't exist here at least some indirect way? Like having a special mark to the variable which "holds" the ressource and operations on the ressource are executed in the mainthread and the result returned in the executing thread?

And thanks for your fixes :)

A worker can have resources, stackables can manipulate those resources, any 
context with a reference to the stackable can read the results of it's work.

But there is no way, and there's not likely to be a way, to share resources among 
threads.

parent:: and self:: bug resolved, tested inherited constructors they are now 
working in git.

I will still leave this open until I have updated the documentation, the thing to 
remember is that static variables now have the scope of a thread, not the scope 
of a process like they do without pthreads. So you can still read/write them 
safely and without segfaulting or errors, better :)

Despite my instincts, I have made resource sharing a possibility, examples for a 
multi-threaded socket server are now in git, and working.

I will still leave this open until the documentation is updated, I am unsure of 
how much will work, and we are still testing, so not much point in updating the 
documentation just yet until I know what to document exactly, hopefully anyone 
having the same issues will come across this bug report for now.

I have now updated the documentation with inline examples, it should all be 
available on php.net main docs today, I will also push another release of what is 
in git today to pecl so everything is up to date.