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/
