:) all is not lost.
if you assume that you want some form of notification, but you want to leave it unspecified because you're not sure what each apr thread will be used for, then you can make a somewhat generic "kill off other threads" cleanup. so for example, when an httpd thread is created it would register http_thread_cleanup which would use whatever magic global int die_now_please = 1, and release some condition variable, or throw something into a queue / and so on. that would be registered in the "parent" thread's pool -- and would only be invoked by the "parent" thread. pools let you do this, you don't need the mutexes for it, you just have to be explicit about parallelism. (combine that with a root pool per thread and then we can remove alloc_mutex and free lists and push the real gnarly problems into the libc malloc where it's probably best solved.) the main problem i see is that there's no easy way to break a thread out of accept(). but folks may want to look at something such as SIGIO, or having a single acceptor thread per process, or ... using kevent (freebsd), rt signals (linux), /dev/poll (solaris), completion ports (nt) which i believe all have other methods of stuffing events into the queues. for legacy systems (which probably don't have native threads to begin with) you can just use SIGTERM like we did in 1.3 and block it everywhere except during accept(). if i were to write a webserver today i'd probably start with a model such as kevent or rt signals and make the rest of the old legacy world emulate that, because those are the way of the future (and the past actually, vms had this model :). i don't care about performance on legacy operating systems. -dean On Tue, 17 Jul 2001, Aaron Bannert wrote: > Uh...you knew that already, didn't you... duh... > > jeez now i'm the smartass ;) > > -aaron > > > On Tue, Jul 17, 2001 at 08:43:18AM -0700, Aaron Bannert wrote: > > Normally this would be done (in POSIX) with pthread_cancel(), passing it > > the pthread_t from the other thread. > > > > Unfortunately, this is not a part of APR because many of the current OS > > implementations of this mechanism will leak resources (aparently in the > > kernel), and that is bad. > > > > -aaron > > > > > > On Tue, Jul 17, 2001 at 01:32:52AM -0700, dean gaudet wrote: > > > On Sat, 14 Jul 2001, Sander Striker wrote: > > > > > > > The way I see it, each process has a single pool instance as the parent > > > > for all the threads. Resetting or destroying that pool should > > > > effectively > > > > kill all threads. What am I missing? > > > > > > how does a thread kill another thread? > > > > > > -dean > >