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.

> 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.

Regards,
Mladen.