httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof>
Subject Re: I/O filters & reference counts
Date Mon, 28 Dec 1998 03:48:16 GMT
On Sun, 27 Dec 1998, Alexei Kosut wrote:

> On Sun, 27 Dec 1998, Ed Korthof wrote:
> > A while back, I indicated I'd propose a way to do reference counts w/ the
> > layered I/O I want to implement for 2.0 (assuming we don't use nspr)...
> > for single-threaded Apache, this seems unnecessary (assuming you don't use
> > shared memory in your filters to share data amoung the processes), but in
> > other situations it does have advantages.
> You've probably covered this before, but can you give an example of why
> this would be useful? I'm not doubting that it is, but it would be nice to
> have an example. e.g., it doesn't seem necessary for, say, implementing a
> filter version of SSI.

Here's one example: you have a system where a template file is partially
parsed (globally) for inserting generic (ie.  non-request based)
information in the first layer.  It is stored in the partially rendered
form at an intermediate layer; a layer further down (or up, I always get
this confused) handled request-level rendering (inserting a history bar,
eg.) and delivers it to the client. 

Thus you have:

template on disk    layer 1		    layer 2

contains directives parses one set of	    handles final set
for both layers     directives, and does    of directives (per-
                    (expensive) database    request rendering)
		    calls to render the     
		    results.  the results
		    are cached for 20 min

If the two layers are part of the same application, then it might be
possible to combine them, and remove the need for shared memory w/
reference counts.  (You'd still want to share the memory amoung multiple
threads, and you might wind up doing equivalent operations, but you
wouldn't need this built into the core.)  But if they were in different
applications, then you wouldn't be able to do that -- and you'd neeed to
do a memcpy on the partially rendered results for each request.

To be honest, I've been exploring this largely because it seemed the
consensus the last time this came up.  While I can see clear applications
for I/O layers, the uses for reference counts are (from my perspective) 
mostly theoretical. 

> > pools have a reference to the data & to a counter; when each pool is
> Tip: Please avoid the use of the glyph & as an abbreviation for 'and' when
> discussing C pointers. This confused the heck out of me for a couple of
> minutes ;)

<rueful laugh> yeah, will do.  It was briefly a bit confusing even to me
when re-reading.

> > It might make sense to build a more general reference counting system; if
> > that's what people want, I'm also up for working on that.  But one of the
> > advantages the pool system has is its simplicity, some of which would be
> > lost.
> The pool system has a nice external simplicity, but also an internal one.
> It seems to me that adding ref-couting to it makes it internally a lot
> more complex. Is that something that's desirable? One can make the same
> sort of arguments as when we were talking about pfree() a few months ago.

I think adding reference counting in general is not worthwhile.  The
system which I'm describing wouldn't add terribly to the internal
complexity of the pools, though -- you'd just have an extra cleanup
function, which would walk down the list of 'shared' blocks (this list
would often be empty), decrementing reference counts & freeing where

But I'd have to admit that I'm not sure it's worthwhile (in terms of the
time requied to develop it, compared with the benifits it'd offer) even in
the limited sense described above.

History repeats itself, first as tragedy, second as farce. - Karl Marx

View raw message