Modules in own address space.

[Ben Hyde <bh...@pobox.com>]

I'm building a plugin to Apache, and I seem to be
swallowing a bigger project than I expected.  I thought
I'd share the pain a little.

The current module API design is a hybrid of call backs and data
structures.  This is nice, but it makes it hard to place
the module in it's own address space.  In my case this is
necessary.  I can't take the risk of letting a third party's
code into my system, nor can I coerce Apache's architecture
into that found inside of my system.

Of course placing a module in it's own address space is
generally desirable since the lifecyle of these satilite systems
badly needs to be decoupled from that of Apache.  My main
system stays up for weeks at a time, and the coupling
I'm building to Apache stays up for about a day at a
time, of course the Apache processes can have shorter lifecyles.
In other senarios: authorization, cgi, etc. the satilite
process may want to run a range from shorter to longer
that of Apache.

All that tends to lead one toward an plugin API design that
uses a transport layer between Apache and the plugin that
is stream like (possibly using shared memory) and is able
to manage to keep the satilite and Apache in synch around
the request/server data structures.

I seem to be on my way to keeping three sets of books to
do this.  One set of request/server data structures for
Apache, one for my plugin, and one in the satilite process.
I then block compare so I can stream diffs betwix the
other processes in the pair.

Have other people climbed out on this limb or something
similar?

 - ben h.

Re: Modules in own address space.

[Dean Gaudet <dg...@arctic.org>]

You might want to look at the register_other_child API as a method of
maintaining the external program.  This is one of the applications I had
in mind when writing it.  The only example code for using it is in
main/http_log.c. 

Dean


On Sun, 23 Nov 1997, Ben Hyde wrote:

> 
> I'm building a plugin to Apache, and I seem to be
> swallowing a bigger project than I expected.  I thought
> I'd share the pain a little.
> 
> The current module API design is a hybrid of call backs and data
> structures.  This is nice, but it makes it hard to place
> the module in it's own address space.  In my case this is
> necessary.  I can't take the risk of letting a third party's
> code into my system, nor can I coerce Apache's architecture
> into that found inside of my system.
> 
> Of course placing a module in it's own address space is
> generally desirable since the lifecyle of these satilite systems
> badly needs to be decoupled from that of Apache.  My main
> system stays up for weeks at a time, and the coupling
> I'm building to Apache stays up for about a day at a
> time, of course the Apache processes can have shorter lifecyles.
> In other senarios: authorization, cgi, etc. the satilite
> process may want to run a range from shorter to longer
> that of Apache.
> 
> All that tends to lead one toward an plugin API design that
> uses a transport layer between Apache and the plugin that
> is stream like (possibly using shared memory) and is able
> to manage to keep the satilite and Apache in synch around
> the request/server data structures.
> 
> I seem to be on my way to keeping three sets of books to
> do this.  One set of request/server data structures for
> Apache, one for my plugin, and one in the satilite process.
> I then block compare so I can stream diffs betwix the
> other processes in the pair.
> 
> Have other people climbed out on this limb or something
> similar?
> 
>  - ben h.
> 
> 
> 

Re: Modules in own address space.

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Sun, 23 Nov 1997, Ben Hyde wrote:

> I'm building a plugin to Apache, and I seem to be
> swallowing a bigger project than I expected.  I thought
> I'd share the pain a little.

Hey, that's what we're here for :)

[...]

> All that tends to lead one toward an plugin API design that
> uses a transport layer between Apache and the plugin that
> is stream like (possibly using shared memory) and is able
> to manage to keep the satilite and Apache in synch around
> the request/server data structures.

[...]

> Have other people climbed out on this limb or something
> similar?

If I understand what you're saying, I think I have. When I wrote mod_jserv
(which lets Apache run Java servlets), it was neccessary to have the part
of the module that's written in Java be external to Apache, not only
because the JNI embedding thing doesn't work very well on all OSes (and
I'm not sure I'd want a Java interpreter in each and every Apache
process), but because we wanted all servlets to run in the same process,
so the Java multithreading thing would work out right.

So I used an idea I stole from Sun's mod_servlet, which they stole from
FastCGI. Basically, there's a process running that actually generates
content. An Apache module receives a request, opens a socket (or already
has one open) to this process, gives it the data about the request, gets
the content back, and feeds it to Apache.

It isn't the greatest model, and there are certainly some problems with it
in a number of ways, but for the most part, it works.

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *