S_L_U_A for worker MPM?

[Brian Pane <br...@cnet.com>]

One of the open items in the STATUS file is:

    * Performance: Get the SINGLE_LISTEN_UNSERIALIZED_ACCEPT
      optimization working in worker.  prefork's new design for how
      to notice data on the pod should be sufficient.

I'm willing to spend some time this week on this issue, but first, can
somebody clarify how prefork is handling the pipe-of-death?

It looks like prefork children only check the pod upon completion of
a request.  Is that all there is to it, or am I missing something?

Thanks,
--Brian

RE: S_L_U_A for worker MPM?

[Ryan Bloom <rb...@covalent.net>]

> > The easiest way to remove the S_L_U_A from the worker MPM is to
remove
> all
> > signals from the MPM.
> 
> ++++1!
> 
> > Basically, we have a single thread that currently
> > sits in sigwait, which is just waiting for a signal.  We then have
every
> > other thread sitting in accept waiting for something to wake them
up,
> > either a real connection or a fake one for the POD.  It makes a lot
of
> > sense to make the parent process always use the POD for all
> > communication.  If this happens, then the thread sitting in sigwait
> could
> > easily just sit in poll waiting for data from the parent.  If it
gets a
> !,
> > then the process should just die, if it gets a #, then it should
perform
> a
> > graceful (The chars don't matter, just the idea).  Since the thread
in
> > poll() is always the main thread, it is just fine to just call exit
to
> > terminate the process immediately.
> 
> Perhaps not fine to just call exit on a shutdown. I think Linux (at
least
> some kernel
> levels) has a serious problem with letting the main thread die w/o
killing
> off the other
> threads in the process first. If you let the main thread exit before
> allowing the other
> threads to exit, you end up with a hosed process that doesn't go away.
I
> presume this is a
> bug in the Linux pthread implementation...

You may be right about that, I can't really remember.  However, we have
the same problem right now, because we have a single thread that sits in
a sigwait, waiting for a signal in the graceless case.  Moving it to
listening on a pipe shouldn't change the rest of the logic.  So if this
is a bug, we already know how to deal with it hopefully.  :-)

Ryan

Re: S_L_U_A for worker MPM?

[Bill Stoddard <bi...@wstoddard.com>]

> The easiest way to remove the S_L_U_A from the worker MPM is to remove all
> signals from the MPM.

++++1!

> Basically, we have a single thread that currently
> sits in sigwait, which is just waiting for a signal.  We then have every
> other thread sitting in accept waiting for something to wake them up,
> either a real connection or a fake one for the POD.  It makes a lot of
> sense to make the parent process always use the POD for all
> communication.  If this happens, then the thread sitting in sigwait could
> easily just sit in poll waiting for data from the parent.  If it gets a !,
> then the process should just die, if it gets a #, then it should perform a
> graceful (The chars don't matter, just the idea).  Since the thread in
> poll() is always the main thread, it is just fine to just call exit to
> terminate the process immediately.

Perhaps not fine to just call exit on a shutdown. I think Linux (at least some kernel
levels) has a serious problem with letting the main thread die w/o killing off the other
threads in the process first. If you let the main thread exit before allowing the other
threads to exit, you end up with a hosed process that doesn't go away. I presume this is a
bug in the Linux pthread implementation...

Bill

Re: S_L_U_A for worker MPM?

[Ryan Bloom <rb...@ntrnet.net>]

The easiest way to remove the S_L_U_A from the worker MPM is to remove all
signals from the MPM.  Basically, we have a single thread that currently
sits in sigwait, which is just waiting for a signal.  We then have every
other thread sitting in accept waiting for something to wake them up,
either a real connection or a fake one for the POD.  It makes a lot of
sense to make the parent process always use the POD for all
communication.  If this happens, then the thread sitting in sigwait could
easily just sit in poll waiting for data from the parent.  If it gets a !,
then the process should just die, if it gets a #, then it should perform a
graceful (The chars don't matter, just the idea).  Since the thread in
poll() is always the main thread, it is just fine to just call exit to
terminate the process immediately.  The biggest problem will be how to
wake up the thread that is currently sitting in accept.

Ryan

On Mon, 21 Jan 2002, Greg Ames wrote:

> Brian Pane wrote:
> 
> > I'm willing to spend some time this week on this issue, but first, can
> > somebody clarify how prefork is handling the pipe-of-death?
> > 
> > It looks like prefork children only check the pod upon completion of
> > a request.  Is that all there is to it, or am I missing something?
> 
> There has to be a way to unblock accept()s when a graceful restart happens in
> order to get rid of the apr_poll.  I think prefork depends on the logic in
> mpm_common.c::ap_mpm_pod_[signal|killpg] that sends dummy connects to do this in
> situations where there's low/no traffic from the network. (disclaimer: haven't
> studied the code recently)
> 
> btw, some of the workers_may_exit checks may not be necessary any more, so we
> might be able to eliminate some conditional branches in the mainline path.  The
> threaded MPM had the possibility of workers_may_exit getting set asynchronously
> on thread x, and apparently we wanted thread y to know ASAP. (same disclaimer)
> 
> Greg
> 

-- 

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------

Re: S_L_U_A for worker MPM?

[Greg Ames <gr...@remulak.net>]

Brian Pane wrote:

> I'm willing to spend some time this week on this issue, but first, can
> somebody clarify how prefork is handling the pipe-of-death?
> 
> It looks like prefork children only check the pod upon completion of
> a request.  Is that all there is to it, or am I missing something?

There has to be a way to unblock accept()s when a graceful restart happens in
order to get rid of the apr_poll.  I think prefork depends on the logic in
mpm_common.c::ap_mpm_pod_[signal|killpg] that sends dummy connects to do this in
situations where there's low/no traffic from the network. (disclaimer: haven't
studied the code recently)

btw, some of the workers_may_exit checks may not be necessary any more, so we
might be able to eliminate some conditional branches in the mainline path.  The
threaded MPM had the possibility of workers_may_exit getting set asynchronously
on thread x, and apparently we wanted thread y to know ASAP. (same disclaimer)

Greg