From dev-return-17117-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Aug 22 04:42:04 2006 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 12507 invoked from network); 22 Aug 2006 04:42:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Aug 2006 04:42:04 -0000 Received: (qmail 65197 invoked by uid 500); 22 Aug 2006 04:42:01 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 65157 invoked by uid 500); 22 Aug 2006 04:42:01 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 65145 invoked by uid 99); 22 Aug 2006 04:42:01 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Aug 2006 21:42:01 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [207.155.248.4] (HELO repulse.cnchost.com) (207.155.248.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Aug 2006 21:42:00 -0700 Received: from [192.168.0.21] (c-24-15-193-17.hsd1.il.comcast.net [24.15.193.17]) (as wrowe@rowe-clan.net) by repulse.cnchost.com (ConcentricHost(2.54) Relay) with ESMTP id 28F1D2E2E; Tue, 22 Aug 2006 00:41:30 -0400 (EDT) Message-ID: <44EA8ADA.7050209@rowe-clan.net> Date: Mon, 21 Aug 2006 23:40:58 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Mladen Turk CC: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= , APR Developer List Subject: Re: [PATCH] WIN32 allow destructors for apr_threadkey_private References: <44E9696D.3080802@apache.org> <44E9F449.2@xbc.nu> <44E9FC3B.1050609@rowe-clan.net> <44EA8533.2090708@apache.org> In-Reply-To: <44EA8533.2090708@apache.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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.