From dev-return-20202-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon May 19 15:23:49 2008 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 71015 invoked from network); 19 May 2008 15:23:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 May 2008 15:23:49 -0000 Received: (qmail 97678 invoked by uid 500); 19 May 2008 15:23:50 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 97617 invoked by uid 500); 19 May 2008 15:23:49 -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 97606 invoked by uid 99); 19 May 2008 15:23:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2008 08:23:49 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.202.165.33] (HELO smtpauth11.prod.mesa1.secureserver.net) (64.202.165.33) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 19 May 2008 15:22:55 +0000 Received: (qmail 23212 invoked from network); 19 May 2008 15:23:14 -0000 Received: from unknown (71.239.140.137) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 19 May 2008 15:23:12 -0000 Message-ID: <48319B5F.8070806@rowe-clan.net> Date: Mon, 19 May 2008 10:23:11 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Mladen Turk CC: APR Developer List Subject: Re: Backporting r657500 References: <483102E2.5090103@apache.org> <48310F3B.7070909@rowe-clan.net> <48312300.4000901@apache.org> In-Reply-To: <48312300.4000901@apache.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Mladen Turk wrote: > "The pool cleanup of apr_shm_create (apr_shm_destroy) > also removes the named resource" > Now this is not true for win32, because the created > file never gets deleted afterwards, so IMHO this > should be fixed by actually deleting the mapping file > in shm_cleanup (distinguishing create/attach of course) +1!