On Mon, 28 Feb 2005, Bob Beaty wrote:
Which is my concern.
I've looked at the code differences, and it appears that this modification works for running different source files through the engine, but I'm concerned about the safety of zend_eval_string() if I initialize the engine in one thread and then try to have several threads calling zend_eval_string() on different strings.
It will not work, as I can see. It works fine, when I do some preparations, like:
thr=pthread_self();
tsrml=ts_resource_ex(0, &thr);
php_request_startup(tsrml);
zend_eval_string("But, I must note, that there are no waits for the "thread to start
current thread" in the parent thread in my situation.
Maybe, the code above is not correct (I'm new to PHP's internals), but it works correctly.
I'm not convinced that simply making the php_embed_module thread-local is going to work either. I'm concerned that the engine was written with the idea that only one thread can be initializing the php_embed_module and making calls to zend_eval_string(). If this is the case, then I'd have to re-write a lot more than php_embed.c to get thread-safety out of the engine.Imagine, we have (usually) situation, when we are running a function in a separate thread (such idea is partially realized in pecl/threads).
Or am I on the wrong track?
So, if there are several threads working with one parsed script, we need to provide a kind of task context for each thread + mechanics for sync/async methods.
...maybe, I'm on the wrong track.... :)
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
