Martin Kutschker <[EMAIL PROTECTED]> writes: > Date: 31 Jul 2002 12:12:47 -0400 > To: [EMAIL PROTECTED] > From: Jeff Trawick <[EMAIL PROTECTED]> > Subject: SSLMutex directive, PR 8122 > Message-ID: <[EMAIL PROTECTED]> > > > 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
