Return-Path: Delivered-To: apmail-httpd-modules-dev-archive@locus.apache.org Received: (qmail 44315 invoked from network); 7 May 2008 13:04:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 May 2008 13:04:38 -0000 Received: (qmail 16448 invoked by uid 500); 7 May 2008 13:04:39 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 16427 invoked by uid 500); 7 May 2008 13:04:39 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 16410 invoked by uid 99); 7 May 2008 13:04:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 May 2008 06:04:38 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cesarbs@gmail.com designates 209.85.162.181 as permitted sender) Received: from [209.85.162.181] (HELO el-out-1112.google.com) (209.85.162.181) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 May 2008 13:03:53 +0000 Received: by el-out-1112.google.com with SMTP id n30so21696elf.24 for ; Wed, 07 May 2008 06:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=eJe8q/rOWn/glrxZCqdtJ/qyDzDyqT1gvNEluJXpqkY=; b=iatGoMprNC8W8c4njmUCEwg3zHq5fEOET+7M3QeO15RAb//zURt4zupwe1NfRast5Z/rWJ918FicQqDuth0oqpGbM3IcZyvdAutxsShVT7e1dK2Kx/IDdgIKMygm/1ccMkgBvgx9OmSOCXvXgWFfirMfc/5xmGNKLirW3O+9pi8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nIVkoE0FZ0O/HUfhnlf5+8ikFkq1PfJLfl5glWnYOY4mmY5gsSy12LQfSEgawOLwS7jA+6F7an/rNorrkNJ3Xb6dYKPPeWaIOrBG6iwS5Z28lE6GLdXQBRnsf/aX0c6em2C4NxZN9YlSMPWBwJ/v43CwnyFFeQHQ9h4b7eMAzrQ= Received: by 10.142.162.5 with SMTP id k5mr867227wfe.53.1210165447298; Wed, 07 May 2008 06:04:07 -0700 (PDT) Received: by 10.142.224.21 with HTTP; Wed, 7 May 2008 06:04:07 -0700 (PDT) Message-ID: Date: Wed, 7 May 2008 10:04:07 -0300 From: "=?ISO-8859-1?Q?C=E9sar_Leonardo_Blum_Silveira?=" To: modules-dev@httpd.apache.org Subject: Destroying global mutexes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org Hi all, I am having some issues when registering cleanups to destroy global mutexes created in my module's post_config phase. Basically, if I register a cleanup in the server pool that calls apr_global_mutex_destroy, the server doesn't survive graceful restarts. In order to restart Apache, I need to stop it and start it again. I was reading the mod_ssl code and noticed it doesn't call apr_global_mutex_destroy at any moment, even though it creates a global mutex using apr_global_mutex_create. Is it "wrong" then to register apr_global_mutex_destroy as a cleanup for the server pool? Also, I notived the post_config hook is run both in the parent and child processes (I am running Apache on Windows, so there is only one child process). That means my global mutex creation calls are being done twice. Isn't that also a bug? I am using the apr_pool_userdata_get/apr_pool_userdata_set "hack" in order to avoid running code twice. I thought that would also prevent the post_config code from being run on the child process, since the child process' pool should be inherited from the parent (is that right?). Any hints on that? Thank you, --=20 C=E9sar L. B. Silveira