Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not.....
Bill > > 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 >
