httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: New graceful restart mechanism.
Date Tue, 05 Jun 2001 00:48:17 GMT
On Mon, Jun 04, 2001 at 03:11:55PM -0700, wrote:
> > Please use a context structure rather than globals. That will allow us to
> > create a POD on a per-thread basis. Then you'll have your desired
> > functionality of a parent telling a child, "hey *you*. please stop."
> I disagree.  By using a simple global variable, we make it much easier to
> use this in an MPM.  I had originally done exactly what you suggested, and
> I found that the code that needed to be added to the MPM was more complex
> than I wanted it to be.

Huh? How hard is it for the MPM to do:

  static ap_mpm_pod_ctx *pod;


  rv = ap_mpm_pod_open(&pod, p);


  rv = ap_mpm_pod_check(pod);

That doesn't look complicated.

Bundling up the thing into a structure, rather than Yet More Globals is
going to be much more helpful for using the POD in different ways.

Globals are inflexible.

> > "pipe_of_death_out" "char_of_death" "one"  What are these variables?
> >
> > Are you really sure you tried this? :-)
> I'm telling you, this all worked, I haven't got a clue why the damn build
> isn't catching these, especially since I did a make clean;make.  This is
> however beginning to bother me.

Note the smiley :-)

But it *is* weird. It isn't a match of "catching" ... any compile should
outright barf on an unknown variable. Maybe you were accidentally using a
different MPM, thus not compilig prefork with the "uses POD" macro?

> > >...
> > > +    apr_sockaddr_info_get(&sa, "", APR_UNSPEC, ap_listeners->sd->port,
0, p);
> >
> > Urk. This magic of looking into ap_listeners doesn't feel right. I don't
> > have an immediate solution, but there must be some kind of abstraction for
> > fetching the listening port.
> Why?  We have the listening port in the ap_listeners list, so we should
> use it.

It feels like it is breaking encapsulation. The POD stuff is "reaching out"
of its box and inspecting arbitrary variables. It is ties between code like
this which makes software brittle.

Like I said: I don't have a recommended solution handy. Simply raising a
yellow flag that some lines are being crossed.


Greg Stein,

View raw message