apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Wed, 18 Jul 2001 02:30:33 GMT

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

yes. I think a single acceptor thread per process is reasonable. And it sets the code up
nicely for

> 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.


> 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.
I completely agree. I have the start of an async/event driven MPM working on Windows with
the ultimate goal of abstracting out the essentials for an event driven API and
implementing them on Windows using completion ports, on FreeBSD with kqueue/kevent,
/dev/poll on Solaris, etc. I know the AIX team is looking into an event API too (I
recommended kqueue/kevent :-)

> -dean


View raw message