You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2001/09/27 00:25:19 UTC
converting AP_CHILD_THREAD_FROM_ID into two macros
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.
2) it makes it more readable (one must admit that it is rather unintuitive
to have a macro that can only be used in a parameter list).
The changes this would incur would be individually small, but they
will have to happen all over the place.
-aaron
Re: converting AP_CHILD_THREAD_FROM_ID into two macros
Posted by Aaron Bannert <aa...@clove.org>.
On Sat, Sep 29, 2001 at 08:50:00AM -0700, Ryan Bloom wrote:
> > 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.
It is actually used a few times in prefork.c, but those uses are unnecessary
(since prefork defines the macro), so yeah we could probably get away with
it just being in the conn_rec. I'll see what I can come up with.
-aaron
Re: converting AP_CHILD_THREAD_FROM_ID into two macros
Posted by Ryan Bloom <rb...@covalent.net>.
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
--------------------------------------------------------------
Re: converting AP_CHILD_THREAD_FROM_ID into two macros
Posted by Aaron Bannert <aa...@clove.org>.
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
Re: converting AP_CHILD_THREAD_FROM_ID into two macros
Posted by Ryan Bloom <rb...@covalent.net>.
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.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------