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 creates an
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 creation is OK so
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 in
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 -
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
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 (ie. a
