> > > > This could be improved a bit, by using
> > > > OOB data to wake up the thread, and we would only check the pod if we
> > > > received OOB data. This is an optimization however, and I am not sure how
> > > > that would work in real-life.
> > >
> > > Err, I'm not sure either :) On which connection would you send OOB
> > > data? How would we detect that there was OOB data? If select(), I
> > > thought we were removing the need for select() (think
> > > "SINGLE_LISTEN_UNSERIALIZED_ACCEPT")... If SIGURG, I thought we were
> > > avoiding signal-based processing (not sure of SIGURG portability
> > > anyway)... I guess I'm missing something real basic here...
> >
> > I was thinking of doing the connect, and actually sending OOB data over
> > the wire. I seem to recall some way to determine when OOB data was read
> > from the network, but I can't find it right now.
>
> You can have SIGURG sent when OOB data is received. You can do
> select()/poll() to see if OOB data has been received. You can call
> recv() or recvmsg() or recvfrom() asking for MSG_OOB. I dunno what
> else there is.
I was really hoping I saw something during the accept phase, but looking
through it, you are correct, what I was remembering was select/poll. :-(
> > > a) weird firewall-like rules on some possibly-weird systems may keep
> > > the connect() from working; admin needs to be aware
> >
> > We are connecting from localhost to localhost. While weird firewall rules
> > may stop this, remember that we are connecting on a port that should be
> > accessible, because it is meant to accept connections. :-)
>
> The rules of firewall-like constructs often distinguish between
> accepting connections vs. requesting new connections. They can also
> be user id or group-specific ("nobody").
>
> This is just something to be aware of when people have shutdown
> problems. The traces after connect() fails will be helpful.
Good point. Something to document and just be aware of.
> > > b) TCP/IP may be dead/dying and socket()+connect() won't work
> > >
> > > I'm not sure how to kill apache on OS/390 when the stack goes away.
> > >
> > > I was told previously by you and possibly others that I couldn't
> > > teach the child process to tell the parent to get the @#$% out
> > > because the stack is dead. If the stack is dead, the user can tell
> > > apache to go away but nothing will happen and the child processes
> > > will (probably) continue looping and getting weird errors on
> > > select() or accept().
> > >
> > > This needs to be solved. For me, simply recognizing the magic
> > > error feedback and using the magic error status (CHILD_EXITFATAL?)
> > > is sufficient.
> >
> > Greg Ames stated quite emphatically, that if the stack dies on a 390
> > machine, the child process will wake up from select. Once that happens,
> > the process will die, if for no other reason than that Apache dies when
> > select returns an error other than EINTR.
>
> We're in select()/poll() on OS/390 only if there is more than one
> listening socket. In general I would expect to be in accept().
Looking at the accept code, assuming accept returns ENETDOWN, we will die
correctly in this case.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
