You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2003/03/28 00:03:31 UTC

[PATCH] 2.0.45 ssl_mutex handling [all platforms]

We do have a problem across platforms;

we skip the code in the ssl_cmd_SSLMutex after the first go around.
The old code used mc->pPool as a permanent pool for the szMutexFile,
but my previous patch used cfg->pool.  So this new patch uses the
full-blown cmd->server->process->pool so the pstrdup'ed name hangs
around for us.

That's not my biggest problem - see the patch to ssl_mutex_init - it
turns out we were creating a new mutex on every graceful restart,
if I read things correctly.  So *no* platforms had a persistent mutex
for the lifetime of the server.  Verified against 2.0.44 as well, this has
been around a while.  The new patch creates the mutex itself in the
s->process->pool as well so it's truly persistent.

This patch is now tested on Win32, users on other platforms are asked
to test this code.  Comments?

Bill 


[PATCH rev2] 2.0.45 ssl_mutex handling [all platforms]

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
That patch had two bugs.  In _mutex we had already toggled the init
as completed so that flag test was bad, let's just look for mc->pMutex.
The other bug was the string scope created by apr_server_root_relative,
this updated patch keeps the resulting name in the global pool and
trashes the other temp strings with the cmd->temp_pool.

I've committed these patches to httpd-2.1 so they are well documented
and easy to retrieve and test.

Bill

At 05:03 PM 3/27/2003, William A. Rowe, Jr. wrote:
>We do have a problem across platforms;
>
>we skip the code in the ssl_cmd_SSLMutex after the first go around.
>The old code used mc->pPool as a permanent pool for the szMutexFile,
>but my previous patch used cfg->pool.  So this new patch uses the
>full-blown cmd->server->process->pool so the pstrdup'ed name hangs
>around for us.
>
>That's not my biggest problem - see the patch to ssl_mutex_init - it
>turns out we were creating a new mutex on every graceful restart,
>if I read things correctly.  So *no* platforms had a persistent mutex
>for the lifetime of the server.  Verified against 2.0.44 as well, this has
>been around a while.  The new patch creates the mutex itself in the
>s->process->pool as well so it's truly persistent.
>
>This patch is now tested on Win32, users on other platforms are asked
>to test this code.  Comments?
>
>Bill