<[EMAIL PROTECTED]> writes:
> > > 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.
> > ---------/----------
> >
> > This feels like a reasonable the way to go but when this has been
> > brought up before I've had some general worries about it that perhaps
> > folks can dispel. (Maybe I'm just mad because when I got the great
> > idea to use connect() it wouldn't do what I wanted it to do :) )
> >
> > I remain at least a little concerned about using connect() because
> >
> > 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.
> > 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().
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
