Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> >> I had a similar issue with this proposal, and came to a different possible >> solution ... we could run the destructors as part of the thread return >> processing from our apr thread start function when the thread returns >> control. > > Hmm, but this would limit the usage by threads only created with > apr, and in that case one can use thread attributes instead threadkey.
Yup... as I suggested, do we care? Can anyone point at some cases that this would be a realistic scenario - non-apr threads using apr threading APIs? A related question; we should only invoke destructors for apr managed thread datum, right? I think this is how your patch works, but it's a similar point. I like the msvcr registered cleanups, but then we need to ensure that apr is never unloaded until process termination. >> I also find the table code very ugly... allocating a pool datum to track >> these >> keys in a hash seems in the global pool seems to make so much more sense. > > A performance optimization is fine if it won't cause constant allocation > when the key is created. Well we have the mystery constant 1088 * 2(8 byte) objects due to alignment, so I don't see that's a big problem. I imagine most cases the registered cleanups would be much fewer.
