> > > 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..... > > > > At this moment, yes, otherwise it defaults to the parent/private, child/private > > model. Do you want that changed, effective now, to always have a shared score? > > It must become a shared score before we can proceed to multi-process, but we > > aren't quite there, yet. > > In the cases where we want/need a shared scoreboard, I would prefer for the parent to > derive a safe name and tell the child the name. I see no goodness in complicating the > config with a directive that does not provide a distinct benefit to the user. IMHO, >the > name of the shared segment (and the process for deriving the name) is best kept >under the > covers.
You didn't answer my question :) First off, to your response, IF the user specifies a filename, I strongly believe we use that name. If the user leaves ScoreboardFile unspecified, then we do what _we_ feel is best. I believe this applies to Win32 and Unix, as well, and made that comment to Aaron's patch. Now, if the user doesn't specify a ScoreboardFile _today_, then we leave well enough alone, and the parent and child don't share a scoreboard. That's fine, until we go to multiple processes. Unless we want to begin using the shared score today, always. As far as our inventing that shared resource [If the user assign the file backing with ScoreboardFile]; I have a philosophy. You create the child detached. We dup the handle to the shared score to the child's process, and pass it down the pipe. We need the apr_os_shm_get/put to make this happen, but that's a trivial patch. My Q to you - share a scoreboard, starting today, always? Or only if we actually care? [3rd party module/app or when we get to multi-proc.] Bill
