httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: cvs commit: httpd-2.0/server scoreboard.c
Date Thu, 24 Jan 2002 16:11:46 GMT

> > > > 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
>


Mime
View raw message