>>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".
>It's more correct to say that it assumes APR "does the right thing",
which
>it does. Under Win32 it creates an unnamed mutex ala the mpm.
The creatio
At 11:01 PM +0100 3/26/03, Andre Schild wrote:
>
>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".
>
It's more correct to say that it assumes APR "does the right thing", which
it does. Under Win32 it cr
At 04:01 PM 3/26/2003, Andre Schild wrote:
>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 (
>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 tr
Guys - I'm digging this out right now, but I'm having trouble keeping
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.
File mutex modes aren't really win32 files - t
>I'm +1 for having the SSLMutex code autogen a bogus fname. I can add
>this quickly... but please read below.
In this case update the docu in the .h file accordingly.
>vary. For example, would /tmp/apr879879 be OK under Win32? Again,
>this is just the sort of abstraction I think would be prefect i
