httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: httpd-2.0/server scoreboard.c
Date Thu, 24 Jan 2002 06:37:04 GMT
> aaron       02/01/22 22:51:18
> 
>   Modified:    server   scoreboard.c
>   Log:
>   Although this patch is technically correct, I'm not happy with
>   the way it gets things done. OTOH, it is a simple enough change
>   to get things working correctly for now. I will come up with
>   the right way to do this in the next couple days.
>   
>   This patch re-enables the use of anonymous shared memory in the
>   scoreboard on platforms that have it.

Well chicken 'n eggs... one way or another this patch broke win32.

Now I'm researching what/how to get both anon and file backed win32
shm.c working.  Fixing that bug makes the win32 startup failures
disappear.

But this does break a simple idea behind the win32 shmem.  I had
intended to create the scoreboard as shared, only if named.  The
create anon _does_ create anon memory on win32, ENOTIMPL is not
an acceptable solution.

The issue is that we are a forked platform.  Therefore, you can't
make the assumption that anon is preferred.  Maybe you prefer it,
but we on win32 sure don't, and other platforms may agree for other
reasons.

So I suggest we back out the patch, and instead, use this logic;
rather than always creating the DEFAULT scoreboard name, leave it
Null on all platforms that support anon memory.  If the user specifies
a filename, use it.  If the user omits the ScoreboardName, then they
receive anon memory.  And if APR lacks anon support, keep using a
default scoreboard name on the platform.

Does this make any sense?  It would allow 3rd party apps to share and
access the scoreboard by name, when the user configures it, and regardless
of our default preference for that platform.

Bill


Mime
View raw message