> 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
