At 9:31 PM +0100 3/26/03, Andre Schild wrote: >Hello, > >I did some investigations on this message and found the following: > >Using SSLMutex default results in no-filename for the mutex. > In the comments to this, there it stays: > mc->szMutexFile = NULL; /* APR determines temporary filename */ > >We should initialize the mutexfilename with something "unique" in >ssl_engine_config.c > >Instead of: > mc->szMutexFile = NULL; /* APR determines temporary filename */ > >Proposition: > mc->szMutexFile = apr_psprintf(mc->pPool, "%s.%lu", > "Apache_OPENSSLMutex", (unsigned long)getpid()); > >Sidenote: > >The win32 implementations of apr_proc_mutex_create and >apr_proc_mutex_child_init >don't generate a error or print a warning when the (required) >parameter >fname is NULL. >Would be nice if the APR notified this as an error...... >
I'm +1 for having the SSLMutex code autogen a bogus fname. I can add this quickly... but please read below. Also, despite the comments, we don't really honor it. For example, proc_mutex_fcntl_create() doesn't require it and is smart enough to do the right thing. So maybe it's more an issue for APR (that is, have each implementation not only determine if an fname is needed, but also create one ala proc_mutex_fcntl_create(). In fact, I would almost kind of prefer that since naming conventions could vary. For example, would /tmp/apr879879 be OK under Win32? Again, this is just the sort of abstraction I think would be prefect in APR. -- =========================================================================== Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
