Re: SSLMutex directive, PR 8122

[Martin Kutschker <Ma...@blackbox.net>]

Date: 31 Jul 2002 12:12:47 -0400
To: dev@httpd.apache.org
From: Jeff Trawick <tr...@attglobal.net>
Subject: SSLMutex directive, PR 8122
Message-ID: <m3...@rdu88-250-182.nc.rr.com>

> This PR points out a problem with the current SSLMutex handling in
> mod_ssl and provides a patch to resolve it.

Nice to see someone noticing it.

> I'd rather see a different solution:
>
> 1) give SSLMutex the same syntax as AcceptMutex, except that SSLMutex
> has an additional choice: none.

This is not so different. I proposed as well the same syntax as AcceptMutex. But I retained more backwards compatibility having the choices none/no, default/yes, sem and file.

Anyway you are right the file: choice is awkward and inconsistent with other options. How about using my path, BTW I have a new one for 2.0.39 if anyone is interested, but issuing a deprectation warning for the file: choice?

> 2) add SSLMutexFile which is processed like the LockFile directive

Good idea.

Masi 

Re: SSLMutex directive, PR 8122

[Jeff Trawick <tr...@attglobal.net>]

Martin Kutschker <Ma...@blackbox.net> writes:

> Date: 31 Jul 2002 12:12:47 -0400
> To: dev@httpd.apache.org
> From: Jeff Trawick <tr...@attglobal.net>
> Subject: SSLMutex directive, PR 8122
> Message-ID: <m3...@rdu88-250-182.nc.rr.com>
> 
> > This PR points out a problem with the current SSLMutex handling in
> > mod_ssl and provides a patch to resolve it.
> 
> Nice to see someone noticing it.

It is painful to see all the PRs out there, for both the person
submitting and the people who are getting to them as fast as they can
:(

> > I'd rather see a different solution:
> >
> > 1) give SSLMutex the same syntax as AcceptMutex, except that SSLMutex
> > has an additional choice: none.
> 
> This is not so different. I proposed as well the same syntax as AcceptMutex. But I retained more backwards compatibility having the choices none/no, default/yes, sem and file.
> 
> Anyway you are right the file: choice is awkward and inconsistent with other options. How about using my path, BTW I have a new one for 2.0.39 if anyone is interested, but issuing a deprectation warning for the file: choice?

I don't like the "sem" choice either :)

> > 2) add SSLMutexFile which is processed like the LockFile directive
> 
> Good idea.

My biggest concern with the backwards compatibility is that it would
require yet another place where some code determines what type of lock
to get (e.g., if the user specifies "file" then mod_ssl decides that
it likes fcntl better than flock and uses fcntl if available; if the
user specifies "sem" then mod_ssl decides that it likes either SysV
sem or Posix sem better and uses that if available).

I'd rather see APR be the one and only place where mutex preferences
are coded, and I don't think it is necessary for the mod_ssl user to
be able to say "I want a file-based lock; you decide."  It is
sufficient to say "You decide (file-based or not)" or "I want this
particular implementation."  It also leads to simpler documentation.

A secondary concern with the backwards compatibility is that IMHO the
directive is a bit too complex.

If we remove some backwards compatibility then I'd prefer starting
from scratch and deciding again how we want it to work.  At that
point, "none"+"no", "sem", and "file" don't seem worthy.

(I'm not adamant either way...  I'm still mulling it over and am
certainly eager for more people to chime in.  However it turns out,
I'm sure your patch will be at least the basis for the changes.)

Thanks,

Jeff

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...