Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15237
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4223DD44.8030406@akbkhome.com>
Date: Tue, 01 Mar 2005 11:11:00 +0800
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
MIME-Version: 1.0
To: Bob Beaty <drbobbeaty@gmail.com>
CC: Vadka <vvs_php@nsrd.sinp.msu.ru>,  internals@lists.php.net
References: <2005022807371112877%drbob@TheManFromSPUDcom> <42233717.9050107@akbkhome.com> <Pine.LNX.4.60.0502282204290.2142@nsrd.sinp.msu.ru> <729eaf208f6ab01379951b88d8f90b76@gmail.com>
In-Reply-To: <729eaf208f6ab01379951b88d8f90b76@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] How to embed PHP5 into multi-threaded C app?
From: alan@akbkhome.com (Alan Knowles)

I think derick does something like this in SRM,
but basically if you want to load something in the global thread,  and 
let the children inherit the data / classes /function etc.
AFAIR you need to serialize the opcodes, and copy them for each thread. 
(or use something like bcompiler to load cached opcodes for you..)

Basically the engine does thread saftey by having a seperate data store 
for each thread. As far as the engine goes, it treats each thread pretty 
much as a seperate process.. 
There was some code in the threads extension to pass variables between 
threads.., cant remember the status of it though.

The code I posted works pretty well, but I include a file as soon as the 
new thread starts up, and dont have any thread global data at present.

Regards
Alan


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.
>
> 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.
>
> Or am I on the wrong track?
>
>         Bob
>
>
> On Feb 28, 2005, at 1:08 PM, Vadka wrote:
>
>>
>> On Mon, 28 Feb 2005, Alan Knowles wrote:
>>
>>> these still need tidying up alot, but the do work.
>>> http://docs.akbkhome.com/php_embed.c.txt
>>> http://docs.akbkhome.com/php_embed.h.txt
>>> replace the code in php_embed with them, make sure you compile with 
>>> the zts enabled, and the macros's are similar to the original embed 
>>> (use threaded start call at application start up, and thread start 
>>> /start end within the pthread_start(...callback..) method
>>
>> Thread safeness is not a problem for a single thread.
>> The problem is to call user functions from different threads
>> (tsrm_ls pointed to somewhere in different threads, global vars etc 
>> are not protected).
>
>     Thanks,
>         Bob (drbob@TheManFromSPUD.com)
>     The Man from S.P.U.D.
>     We will write no code before it's designed.
>