Re: Which thread/process

[Zeev Suraski <bo...@netvision.net.il>]

On Thu, 12 Aug 1999, Rasmus Lerdorf wrote:

> > I suggest adding an index field to conn_rec. This number is set by
> > the MPM after ap_new_connection is called. This way, mod_cgid can work
> > properly even in an asynchronous threaded server.
> > 
> > I'm guessing this field would be useful to other modules as well.
> > PHP4's TSRM could possibly derive the indices it uses from
> > conn_rec->index.
> > 
> > Thoughts?
> 
> That would work for us.

As far as I recall, that's what Dean wanted to do in the first place.  
Our problem with it remains as it was - we don't have any access to the
conn_rec structure from TSRM.  We'll have to figure out a solution once
Apache 2.0 materializes a bit more.

Generally, I doubt we'd be able to use anything Apache-specific in TSRM,
unless Apache will provide a globally-callable function to get a static &
unique id for the current request.  If that doesn't happen, we'll probably
have to use pthread_self() or something similar, and give up running on
some of the mpm hybrids.

Zeev

-- 
-----------------------------------------------------
Zeev Suraski <ze...@zend.com>     http://www.zend.com/
For a PGP public key, finger bourbon@netvision.net.il

Re: Which thread/process

[Manoj Kasichainula <ma...@io.com>]

I wrote:
> > > I suggest adding an index field to conn_rec. This number is set by
> > > the MPM after ap_new_connection is called. This way, mod_cgid can work
> > > properly even in an asynchronous threaded server.

On Sat, Sep 11, 1999 at 12:13:38PM +0200, Zeev Suraski wrote:
> As far as I recall, that's what Dean wanted to do in the first place.  
> Our problem with it remains as it was - we don't have any access to the
> conn_rec structure from TSRM.

I haven't thought about this too much yet, but I think one possibility
in this case is to split the functionality of ts_allocate_id.  Right
now, it generates a new ID, and sets aside the space for it.  Instead,
let the application supply the new ID. ts_allocate_id would become
more like ts_register_id. PHP proper should be able to dig out the
connection ID and pass it to TSRM pretty easily.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"This letter is clearly the result of too much spinning." -- The Tick

Re: Which thread/process

[Dean Gaudet <dg...@arctic.org>]

On Sat, 11 Sep 1999, Zeev Suraski wrote:

> On Thu, 12 Aug 1999, Rasmus Lerdorf wrote:
> 
> > > I suggest adding an index field to conn_rec. This number is set by
> > > the MPM after ap_new_connection is called. This way, mod_cgid can work
> > > properly even in an asynchronous threaded server.
> > > 
> > > I'm guessing this field would be useful to other modules as well.
> > > PHP4's TSRM could possibly derive the indices it uses from
> > > conn_rec->index.
> > > 
> > > Thoughts?
> > 
> > That would work for us.
> 
> As far as I recall, that's what Dean wanted to do in the first place.  
> Our problem with it remains as it was - we don't have any access to the
> conn_rec structure from TSRM.  We'll have to figure out a solution once
> Apache 2.0 materializes a bit more.
> 
> Generally, I doubt we'd be able to use anything Apache-specific in TSRM,
> unless Apache will provide a globally-callable function to get a static &
> unique id for the current request.  If that doesn't happen, we'll probably
> have to use pthread_self() or something similar, and give up running on
> some of the mpm hybrids.

we could provide you with a hook which gets called whenever the thread
running a connection changes.  inside that hook you'll have the conn_rec. 
stuff whatever you need into thread-local-memory. 

but actually i don't even think that is required.  because you get the
request_rec or conn_rec *every time your module is called*.  i.e. in your
handler you have it.  you may not have it inside your own code, because
you haven't passed the request_rec structure through to all your own
routines.  but you've got the data you need at the point control passes
from apache to php... so you can stuff something into thread-local-memory
if you need to.

Dean