apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject Re: multithreaded pools?
Date Tue, 10 Jul 2001 07:59:41 GMT
On Sun, 8 Jul 2001, Roy T. Fielding wrote:

[clean_child_exit]
>
> It is only called when the child exits and not per-thread.  I think the
> threads are already dead by that point, or locked-up due to some fatal
> error that is the reason why clean_child_exit is being called.

when you say "the threads are dead" you're referring to the httpd threads.
there could be zillions of other threads started up by third party
modules, still running.

but also, if you look at the call sites within threaded.c you'll find that
even the httpd threads are (potentially) still running.

huh, at least one of the call sites -- where apr_thread_create fails looks
like a genuine bug.  exit the PROCESS if you can't create a thread, for
any reason whatsoever?  this is in start_threads.

also, clean_child_exit is called when SIGTERM is received... and makes no
attempt to stop the httpd threads.

so basically clean_child_exit() really should just call exit() and avoid
the possibility of damaging data by calling cleanups owned by other
threads (and with no locking to protect them).

...

anyhow, you've got issues with root pools coming out our ears.  i can
understand that.  a solution which came up ages ago when we first talked
about this was to register a "thread cleanup" in the parent.  the thread
cleanup is a link to the thread's root pool, and because it doesn't go
through the usual parent/child relationship we can handle it specially
(such as including locking while accessing it, this avoids hitting the
fast path that we want there for all other sub pool create/destroys).

now we just need to figure out how to get the thread to rendezvous with
the parent and we can build a cleanup system that works :)

while i am wholly against async notification, i'm not at all against a
unified method of synchronous notification -- a flag somewhere in the
per-thread data indicating "please stop at your earliest convenience".

but i'm still not sure this is useful for clean_child_exit --
clean_child_exit is a lot like the debate about abort() within apr_palloc.
something is royally screwed when this happens, and there's really nothing
graceful you can do... i believe the safest thing is to call exit() as
fast as possible without stopping to try to do anything fancy.

-dean


Mime
View raw message