Re: cvs commit: httpd-2.0/server/mpm/worker worker.c

[Aaron Bannert <aa...@clove.org>]

On Wed, Apr 17, 2002 at 03:45:27PM -0000, trawick@apache.org wrote:
> trawick     02/04/17 08:45:27
> 
>   Modified:    server/mpm/worker worker.c
>   Log:
>   use an independent pool for threads so that when we abandon them
>   during graceless termination the cleanups on pchild won't mess with
>   stuff they are still referencing

Aren't global pools still cleaned up on exit? If the threads are still
running we'll still have the same problem. The only way I see to fix this
is to make sure that all threads have terminated before cleaning up
the pool.

-aaron

Re: cvs commit: httpd-2.0/server/mpm/worker worker.c

[Aaron Bannert <aa...@clove.org>]

> > Aren't global pools still cleaned up on exit? If the threads are still
> > running we'll still have the same problem. The only way I see to fix this
> > is to make sure that all threads have terminated before cleaning up
> > the pool.
> 
> I don't see that they're getting cleaned up on exit.

Pools that are created with a NULL parent are actually created as
child-pools of the global_pool. The global_pool is destroyed in
apr_pool_terminate(), which is called from apr_terminate(), which
is registered with atexit().

> As far as making sure all threads have terminated before cleaning up
> the pool:  How do we do that in a graceless shutdown?  If we hang
> around much longer, the parent is going to kill us and we won't be
> able to run cleanups anyway.

I don't see any good way out of this situation, here are two bad ways
I see out:

1) check for workers_may_exit upon returning from any EINTR-returning syscall
   Con: yuck, the number of places where we would have to do this is
        way too large.

2) introduce apr_thread_cancel()
   Con: a) many thread libraries leak kernel resources when threads are
           cancelled.
        b) We'd also have to introduce apr_thread_setcancelstate, et al.
           *and* we would have to be sure to clean up thing like the
           accept mutex (it would be bad to be canceled while holding
           the accept mutex).

A couple questions:
  - What happens when we call shutdown() on the listen socket? Are
    accepted sockets allowed to remain (I'm assuming so).

  - Could the listener thread keep a list of accepted socket descriptors
    and then close them all when we receive the signal to gracelessly
    stop the server? We could optionally _not_ handle the resulting
    socket errors (Afterall, that might be good information to have --
    the admin just intentionally killed off a bunch of connections.)

-aaron

Re: cvs commit: httpd-2.0/server/mpm/worker worker.c

[Jeff Trawick <tr...@attglobal.net>]

Aaron Bannert <aa...@clove.org> writes:

> On Wed, Apr 17, 2002 at 03:45:27PM -0000, trawick@apache.org wrote:
> > trawick     02/04/17 08:45:27
> > 
> >   Modified:    server/mpm/worker worker.c
> >   Log:
> >   use an independent pool for threads so that when we abandon them
> >   during graceless termination the cleanups on pchild won't mess with
> >   stuff they are still referencing
> 
> Aren't global pools still cleaned up on exit? If the threads are still
> running we'll still have the same problem. The only way I see to fix this
> is to make sure that all threads have terminated before cleaning up
> the pool.

I don't see that they're getting cleaned up on exit.

As far as making sure all threads have terminated before cleaning up
the pool:  How do we do that in a graceless shutdown?  If we hang
around much longer, the parent is going to kill us and we won't be
able to run cleanups anyway.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...