httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: converting AP_CHILD_THREAD_FROM_ID into two macros
Date Sat, 29 Sep 2001 15:30:53 GMT
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.

-aaron

Mime
View raw message