> > > > 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 :) You answered my question with a question :-) Seriously... I'm a bit of a performance nut. If the shared scoreboard does not impose a performance hit, then may as well begin using it (assuming it even works of course:-). We clearly need to introduce multiple child processes under Windows and the shared score is a prereq.
> First off, to your response, IF the user > specifies a filename, I strongly believe we use that name. +1 > 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. +1 > > 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.] I was not able to parse all of the last two paragraphs... Any downsides to a shared score today? If not, then lets begin using a shared score now. Bill > Bill >
