On Sun, 26 Aug 2001, Greg Stein wrote: > 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.
That is definitely in-sync with the conclusion that was reached in previous debates on this matter. Ignoring the obvious flexibility and so on and just talking about pure performance, it boiled down to this example: If you force the buckets code itself to do a little extra work each time you create a bucket to (look up the SMS|find its free list|insert your own semantic), then what's going to happen to filters that create a buttload of buckets? They're going to have to do tons and tons of redundant work. It'd be nice if you only had to do that work once and propagate the result to the later buckets. But if you're giving the caller the interface to do that, the caller might as well figure out what SMS it wants wayyyyy ahead of time and stash it somewhere so that you REALLY avoid doing redundant work. All you have to do per-bucket is take a pointer from somewhere (eg the conn_rec) and pass it in. That's clearly a performance gain over any system that involves per-bucket-creation work. > 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. That is another benefit, sure. Though while we're definitely not limited to a single SMS for all bucket types, what I think we're going to see is that the best SMS for buckets in general is one that can hand out little blobs of about 20-60 bytes at a time really really really fast (that's the approximate range of sizes for various bucket structures) and recycle them very efficiently. That's why David and Sander wrote the blocks SMS in the first place--they had this specifically in mind. The SMS would not used to allocate any of the APR structures like apr_file_t, of course, nor would it be used to allocate space for _data_. (Unless somebody makes up an SMS bucket type as a complement to heap and pool buckets, which I'm all for. It would probably look a lot like the pool buckets except that it could fall back on an sms_std instead of having to morph itself to a heap bucket if the SMS got cleaned up.) > 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. That's a good point. There was a tiny comment in there on the variable declaration in the header, but I was counting on the commit message to make it clear that the rest was temporary as well. More comments and a macro would have been a good idea. I'll keep that in mind if I ever have a need for something like this again. Thanks, Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
