httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: converting AP_CHILD_THREAD_FROM_ID into two macros
Date Sat, 29 Sep 2001 15:50:00 GMT
On Saturday 29 September 2001 08:30 am, Aaron Bannert wrote:
> On Fri, Sep 28, 2001 at 10:01:18PM -0700, Ryan Bloom wrote:
> > On Wednesday 26 September 2001 03:25 pm, Aaron Bannert wrote:
> > > Would anyone have a problem if I converted AP_CHILD_THREAD_FROM_ID from
> > > a macro that returns "n,m" to two macros that each return an int?
> > > Something like AP_CHILD_PSLOT_FROM_ID() and AP_CHILD_TSLOT_FROM_ID()?
> > >
> > > I'd like to do this for a couple reasons:
> > >
> > > 1) it gives us the opportunity to reduce the number of times this
> > > calculation is performed. Right now for example with worker, the
> > > calculations (id / HARD_SERVER_LIMIT) and (id % HARD_SERVER_LIMIT) are
> > > performed up to 4 times for a single request (see
> > > modules/http/http_core.c:271), and possibily an additional 3 more times
> > > for each pipelined request. That's only in that one function! I know of
> > > other places that could take advantage of this.  If
> > > AP_CHILD_THREAD_FROM_ID could return something assignable, we could
> > > cache this result and simple use it over and over. I've seen some
> > > pretty bad compiler-generated division routines before that this could
> > > avoid.
> >
> > If we are going to cache it, then we should really just get rid of c->id,
> > and store the process and thread values directly in the conn_rec.  The
> > only reason we made it a single integer, is that it allowed people to
> > assign unique ID's in whatever way they wanted to.  That doesn't seem to
> > be a good reason to keep this as a single integer.
>
> I have no problem with it being a single integer, it's just that the
> macro doesn't return anything that is assignable and reusable. We can
> go so far as to save each half of it in the conn_rec, but the macro is
> used in some places where conn_rec isn't available.

Yeah, but that macro is only going to work on c->id, so we know that we can
get any values from the conn_rec to any function that is currently using the
macro.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message