Re: How to embed PHP5 into multi-threaded C app?

The TSRMLS_DC magic parameter passes around the thread-local storage pointer for the thread; the SG() macro uses that information to get at the sapi_globals struct for your thread. You can also stuff your own SAPI related information into SG(server_context), if you are writing a SAPI: ... in my thread init code ... struct my_globals *g = calloc(1, sizeof(*g)); SG(server_context) = g; ... in the ub write callback ... struct my_globals *g = (struct my_globals*)SG(server_context); If TSRMLS_DC is not present in the function declaration, you can use TSRMLS_FETCH() to summon it out of thread-local-storage. --Wez. On Tue, 1 Mar 2005 04:35:43 -0600, Bob Beaty <drbobbeaty@gmail.com> wrote: > Wez, > OK, I'm with you on this so far, but how do you differentiate > ub_write, log_message, and sapi_error on different threads? It would > seem to me that you'd need to have different functions for each thread > as the calls to ub_write don't include some indication of the thread > that this is being called under. > Then again, maybe it's in the php_embed_module if it's tightly bound > to the thread... For example, if I set the title in the thread-bound > php_embed_module to something specific for each thread then check that > within the call to ub_write() I can see who this 'write' belongs to. > If I'm missing the boat on these function callbacks, or there's an > easier way to capture stdout, stderr, etc. in a ZTS-enabled PHP/Zend > environment, please let me know. > I'm sorry if I seem a bit dense, but I'm trying to figure things out > and design the code before I start writing it. > > Bob > > On Feb 28, 2005, at 11:56 PM, Wez Furlong wrote: > > > ZTS enabled PHP has "strong thread affinity". > > Calls into the engine are thread-safe provided that you have > > previously initialized the engine on that thread. > > > > Note that you should not efree() memory allocated on one thread from > > outside of that thread, on pain of segfault. eg: resources from one > > thread cannot be safely passed on to another thread. > > > > --Wez. > > > > > > > > On Mon, 28 Feb 2005 14:24:05 -0600, Bob Beaty <drbobbeaty@gmail.com> > > 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. > >> > >> > > > > > > Thanks, > Bob (drbob@TheManFromSPUD.com) > The Man from S.P.U.D. > We will write no code before it's designed. > >