:)
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
>
>
