apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Bucket memory allocation (was Re: SMS parm to bucket_foo_create())
Date Mon, 27 Aug 2001 00:30:00 GMT
On Sun, Aug 26, 2001 at 11:35:54AM -0700, Brian Pane wrote:
> Cliff Woolley wrote:
>...
> >makes the API seem.  So we could take a fork in the road from here and
> >leave it up to the buckets to find their thread ID.  Less performant, but
> >not terribly bad.  Probably still better than malloc, though the win is
> >less clear.  Or we could keep going.
> >
> IMHO, it's better to pass the SMS through the API than to force the
> bucket code to look it up via the thread ID, because looking up the
> thread ID isn't necessarily a cheap operation (it may require a system
> call on some platforms).

I would agree with Brian.

Thread-specific globals are just that: globals. Passing as a parameter gives
you clarity/maintainability/flexibility/etc. And it can also mean some real
performance gains in certain places.

Also note that you may want different SMSs based on *applicability* rather
than based on thread. One SMS for FILE buckets, one SMS for pool buckets,
etc. And that determination will be made at create time, rather than through
a "what thread am I on?" question.


On a separate note, I really didn't like that last checkin for the buckets
at all. If you're going to introduce a temporary global variable, and some
temporary logic in every create function, then I'd suggest two things when
you do so:

1) comments on the globals to that effect
2) the per-create logic could be encapsulated in a single macro to minimize
   the line-count changes in those functions, and to focus users on a macro
   which is commented as being transitory.

A few months ago when I changed the calling convention on ap_get_brigade(),
I had intended it to be temporary, with a couple more necessary steps to
make things right. I did not properly communicate that, and since the
temporary step left some things broken, Ryan backed it all out instead. Had
I commented about the transitory nature, we may have made forward progress
rather than backing up. [and yes, I hope to make time to *do* that forward
motion again]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message