httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <>
Subject Re: custom background thread and module sharing a data structure
Date Wed, 11 Mar 2009 08:08:44 GMT
On Wed, Mar 11, 2009 at 02:08, Andrej van der Zee
<> wrote:
> Hi,
> I need to modify Apache and run one custom background thread. In addition,
> my custom modules have to be able to share a data structure with this
> background thread. Did anybody do this before? Is there an example I can use
> as a starting point?

Yes, I did this. I will send you a commented source file sometimes
today or early tomorrow (Central European Time), I don't really have
time now.

The basic idea is to spawn the thread via the apr_thread_* functions
in the post_config hook. The post_config hook is run as root _before_
apache spawns its children and threads. So you are sure that the
thread is unique and that its handler is inherited by the spawned

The post_config hook is run every time apache is restarted or its conf
reloaded (/etc/init.d/apache restart or reload). Thus, you run the
risk to start a new thread each time you reload apache's
configuration. In order to avoid that, register your
thread-stopper/thread-killer in the cleanup function of the conf pool.
The conf pool is destroyed before apache reloads/restarts, so the
thread will be killed.

Regarding the data structure:

You use the same post_config hook (to take advantage of root
privileges and the fact that it is one of the few hooks that are run
in single-process single-thread mode). You create a shared memory
segment via the apr_shm_* header/functions. You register the deleter
of the shm segment in the conf pool cleanup function. This last thing
is important as your module would not only leak memory otherwise but
it would also eat up the operating system's shm descriptors. You can
list the OS's shm segments with "ipcs -m". Check that their number
does not grow after apache reloads/restarts.

Regarding the shm protection against inconsistency: Now here are some
details that I don't remember. There are some mutex mechanisms in
apr_thread_mutex and in apr_proc_mutex. The first protects against
concurrent access of threads in the same process, the second against
concurrent access by processes. I remember I used the first, but I
don't remember why and how did I avoid corruption by concurrent
accesses of different processes.


A: Because it reverses the logical flow of conversation.
Q: Why is top-posting frowned upon?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

View raw message