At 05:43 PM 8/1/2002 +0800, Alan Knowles wrote:
>>It's not about looking at the perl code, that will tell you nothing
>>unless you know perl internals. It's about the way the interpreter
>>works, some of the architecture, that is simular to PHP. In PHP, threads
>>are isolated, kind of like seperate processes, but in threads.
>
>
> From my understanding they are 'forced to be isolated' by the TSRM
> stuff. which looks like it stores globals in something like an
> associated array ( thread id => global c variable - eg. compiler_globals
> etc.), when ZTS is enabled..
>
>>Everything in PHP works that way, so in creating threads for php scripts,
>>you have to have a seperate interpreter. Then you have to create a
>>"bridge" between the threads for shared variables. shmop comes close to
>>what is needed, but not close enough.
>
>the real use of the threading I guess is for people who want to write tcp
>servers, or desktop gtk apps.
>
>Thoughts on accessing 'threaded shared vars'
>------------------------------------------------------------
>$_THREADVAR['gtktext'] type..
>
>php_threads_malloc_lock();
>$_THREADVAR['gtktext']->add_text('some data ouput');
>php_threads_malloc_unlock();
>
>this would I guess involve rather heavy changes to the ZE engine to
>recogize an lock/unlock, copy (rather than refcount) etc. variables that
>where threaded..
>
>
>Threaded objects???
>I guess the other consideration is to have thread variable objects..
>$threadvar = new Thread_Var();
>$threadvar->setNewObject('mywidget','GtkWindow');
>$threadvar->set('mywidget',$gtkobject);
>$var = $threadvar->get('mywidget');
>$var = $threadvar->getArray('key','val');
>$threadvar->callMethod('mywidget', 'add_text','something');
>
>obviously copying and accessing these would probably be easier to cope
>with ( without having to modify heavily the zend engine) - we could do
>'real' copying on the data, rather than refcounting them. and reduce the
>headaches...
>
>>You're much closer to what needs to happen now. But you cannot simply
>>point to the memory for another thread. Doing that will cause problems
>>like you are running into. You actually have to copy a bunch of stuff so
>>each thread is completely independent.
>
>Do you mean we will have to really physically copy the all theopcode data
>from one thread to another?
>
>>
>>
>>I've worked up some code in TSRM to abstract native thread calls, and
>>have started on an extension, but probably won't have it complete until
>>this weekend some time. What you've done now is fairly simular, but
>>pthread specific. Given time, I might have enough done to email a diff
>>containing my work tomorrow night if you want to take a look.
>
>Anything I can do to help - testing, understanding - let me know.
>Sounds Great.
First of all I agree that the two threads shouldn't really share the same
engine instance. It would mean that everything would have to be mutexed.
The solution of creating a separate interpreter instance and having a
couple of methods to share data in between them (like shared memory) is the
way to go.
As creating a copy of a currently executing instance is very hard to do in
my opinion I suggest an API such as:
create_thread("thread.php");
This would create a new instance of the interpreter which would compile
thread.php and start running it. So the actual function/class tables of the
thread could be different from the parent who created it which I think is fine.
Andi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
