apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] WIN32 allow destructors for apr_threadkey_private
Date Tue, 22 Aug 2006 04:40:58 GMT
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.


Mime
View raw message