Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 89480 invoked from network); 24 Nov 2009 20:00:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Nov 2009 20:00:45 -0000 Received: (qmail 16451 invoked by uid 500); 24 Nov 2009 20:00:44 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 16348 invoked by uid 500); 24 Nov 2009 20:00:44 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 16339 invoked by uid 99); 24 Nov 2009 20:00:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Nov 2009 20:00:43 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.216.200 as permitted sender) Received: from [209.85.216.200] (HELO mail-px0-f200.google.com) (209.85.216.200) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Nov 2009 20:00:35 +0000 Received: by pxi38 with SMTP id 38so4927168pxi.10 for ; Tue, 24 Nov 2009 12:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=8kafIcOMBJuXltSuHYVCWhvAVnV1w9PRrchZ0BNKtgM=; b=otWUjL9jzM2w4X08yy9RfZ4WPJ/0js/C1jX+woSe8fJppe5O4OcGYf9TgMkon89HCy XHPxF8xACbngmbffAZ5E+xXFwrrjpAov8EEpM7YH/U8u0dwSD71Ib5iu686u/0XjBKBu oG0nDRY9REajFB4Q8Kh0yd2MQl0jGnGPjDTMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ArE48KZOUNOINm+36cy70E+/AT9z+pHNcWdIRKoCtKTxbS+cBCSrWFf2UEdzr1ka9Y wY8h0SlxIHuqKylQ4d05N5lZgZ68RRMNR+ezsSViqlgl62dUHNrCw7BlLgaEzch2E59d ksZvpL626nY32t3hkgkr7NQwD0uVBSY1OD3Zo= MIME-Version: 1.0 Received: by 10.143.154.33 with SMTP id g33mr728525wfo.300.1259092814594; Tue, 24 Nov 2009 12:00:14 -0800 (PST) In-Reply-To: <4B0C2CD8.7060402@rowe-clan.net> References: <20091124145404.061F823888DC@eris.apache.org> <4B0C0F84.20800@rowe-clan.net> <4B0C2CD8.7060402@rowe-clan.net> Date: Tue, 24 Nov 2009 15:00:14 -0500 Message-ID: Subject: Re: svn commit: r883712 - /httpd/httpd/trunk/docs/manual/mod/core.xml From: Jeff Trawick To: dev@httpd.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Nov 24, 2009 at 1:58 PM, William A. Rowe Jr. wrote: > Jeff Trawick wrote: >> >> What about an optional third argument to Mutex to indicate that the >> pid should be omitted? >> >> Mutex default sysvsem >> Mutex ssl-cache file:/mnt/sesscachedir OmitPid >> etc. > > That seems sensible, but I'm left wondering how many different naming > conventions we can fit on one directive line. =A0Perhaps bOmitPID instead= ;-) > This really becomes harder to follow than the existing multiple-syntaxes. > > Is there any reason not to name these mutexes in MixedCase? I like having the mutex type name as of the filename, and mixed case filenames are unexpected. Beyond that, MixedCase and the "." before the pid suffix don't totally resolve readability. Modules like mod_watchdog with multi-instance mutexes provide an instance string which gets inserted as "-" string prior to the . pid suffix. If the watchdog names are heartbeat and dialup (wild guess; I didn't look closely or try to configure the thing), the files would be logs/watchdog-callback-heartbeat.1359 logs/watchdog-callback-dialup.1359 (These are both instances of the "watchdog-callback" type, which is what would be specified on the Mutex directive.) > Is there any reason we can't invert the arg order, so that we have > > Mutex mutextype:name Resource [Resource ...] [OmitPid] Maybe it would be clearer if the optional OmitPid came before the list of mutexes? > > Of course, default could be assumed here. =A0So the above becomes > > Mutex SysVSem > Mutex file:/mnt/sesscachedir SSLSessionCache OmitPid > > (note the Resource tag can be the actual directive being mutexed, instead > of an alt-name). > > Thoughts? I'm fine with putting the mechanism:dir first followed by a list of mutex type names. I'm not sure about where to put the OmitPid though. I guess you get used to either after a while. (Joe suggested "Mutex name1,name2,name3 mechanism:dir"; I didn't get around to splitting up the first arg to implement that.) >> In the ssl-cache example, the name of the mutex will be simply >> /mnt/sesscachedir/ssl-cache >> >> Does that meet the special SSLMutex requirement? > > Well, it's not strictly SSLMutex, understood that its a general capability > but any other shared-resource that > requires cross process/cross machine mutexing. The SSL session cache mutex is the only use case we have now. At any rate, I take that as a "yes" answer ;) (user somehow says omit-the-pid on the Mutex directive, case closed)