httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject pod+connect doesn't work with threaded idle server maintenance
Date Wed, 20 Jun 2001 13:11:22 GMT
Please tell me how I'm confused...

If we want to take out a single server process to get rid of some
threads because we're now idle, we want to do this gracefully so we
don't trash any current connections.

assume for this scenario:

  threaded + the new pod+connect design and
  SINGLE_LISTEN_UNSERIALIZED_ACCEPT

  process A
    twenty threads in accept()
    twenty threads processing connections

  process B
    twenty threads in accept()
    twenty threads processing connections

  process C
    twenty threads in accept()
    twenty threads processing connections

We want to get rid of a whole process.  

If we write one char to the pod and connect() one time, we tell one
process, call it process A, to go away but we leave 19 other threads
in process A stranded in accept().  Processes B and C are unaffected
so far.

If we write to the pod and connect() again in hopes of waking up one
of the 19 threads stranded in process A, we likely will tell process B
or process C to go away since there is no guarantee which thread will
be awakened by the kernel.

We can't simply connect() ap_daemons_limit*ap_threads_per_child times
and not write to the pod in hopes of waking up the 19 stranded
threads in process B or C, since a given thread in process B or C may
be awakened more than once.

It would seem that the old pod design used by threaded (extra mutex
calls + poll which breaks SINGLE_LISTEN_UNSERIALIZED_ACCEPT) is
required in order to be able to gracefully kill an entire threaded
server process.

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...


Mime
View raw message