>up with your dialog ;-) Be aware we are talking about win32 which >doesn't fork, so it doesn't have the same apr_global_mutex_t in the >child worker process as in the parent process. Correct.
>File mutex modes aren't really win32 files - they are simply >named mutexes. Elsewhere in apr we've translated slash and >backslash to underbars so that the name is a legal object name >(as long as it's 255 characters or shorter.) Correct, the mutexname isn't allowed to have slash's in it >However, this means two servers with "logs/mymutex" end up >being the very same name. It almost seems like we need to >abspath this name, e.g. "c:/apache/logs/mymutex" and then >translate the reserved chars, so you get c__apache_logs_mymutex. >Then you can have c__apache_logs_mymutex happily coexisting >with c__apache21_logs_mymutex. Probably correct too. But currently we are at the stage that the SSLMutex passes a NULL filename in for the mutexname and assumes the apr will generate "something". server/mpm/winnt/mpm_winnt.c however does pass in a NULL filename and wishes to get NULL-filename mutex (ie. a private mutex). So a autogenerated filename from apr will probably break this behaviour. André
