httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject IOL's in APR.
Date Wed, 10 Nov 1999 20:24:28 GMT

Okay, we need to move IOL down to APR, but before we do that, we need to
decide the best way to do this.  It is getting done, but we need to decide
the best way to proceed.  There are two options:

1)  The current solution.  Have a separate IOL type, which you have to
create, and fill out, and then you push the APR type into the IOL, and
continue.

2)  Include the IOL in the APR type.  When you create an APR type, the IOL
will be filled out for you, and you can just continue.

Since option 1 is currently done, I will let people examine the code to
see how it works.

Option 2 requires that we take define the IOL type in a common header
file, and just pass instances of the IOL type to all of the I/O APR type
creation routines.  The type could be typdef'ed for files/sockets/mmap
regions/etc, all pointing to the same IOL type which would look like:

_IOL_
void *
(*read)
(*write)
(*close)
etc.

(Another variation follows at the end of this note).  Because this owuld
not be an incomplete type, functions could easily be called the same way
we call IOL functions now.  The biggest difference is that we do not have
to create an IOL type and push stuff into it, all of that ugliness is done
for us.

This obviously leads into a discussion of the "correct" way to implement
layering (for a version after 2.0).  There are basically two options
again: 

[ This is all provided as food for thought, to be used when making a
decision of the above issues.  I would rather not get into a heated debate
over the right way to do this, because it is most likely not going to end
up in 2.0 anyway.  However, it is a useful discussion, and it gets us
thinking along the right lines. ]
 
1)  Linked lists of IOL variables.
2)  One IOL variable with linked lists for the individual functions.

Option 1 would look like:

fields      Base IOL       CGI IOL    SSI IOL   Speling IOL
void *      ap_socket_t    NULL	      NULL      NULL
(*read)     ap_read        NULL       NULL      NULL
(*write)    ap_write       cgi_write  ssi_write speling_write
(*close)    ap_close_sock  NULL       NULL      NULL
etc.

We don't want to fill in the void* for anything other than the Base
communications IOL, because it will just confuse things.  We definately
don't want to have more than one function for each IOL after the Base one.

Option 2 would look like:

fields      Base IOL       
void *      ap_socket_t -> NULL
(*read)     ap_read     -> NULL
(*write)    ap_write    -> cgi_write -> ssi_write -> speling_write
(*close)    ap_close_sock ->  NULL 
etc.

I think this is self explanitory.

I began this note liking option 2, now I'm not so sure.  Neither one is
really bad, we just need a decision.

I am envisioning that the handler and post_read phases of the modules
would disappear, and be replaced by two filter functions, one for reading
and one for writing.  Those phases would be pushed onto the IOL where we
are currently calling the individual phases.  And they would be called
just after we read the data, or just before we wrote the data.

I am also envisioning two helpers functions, ap_push_iol and ap_pop_iol
( modified to ap_push_iol_read/write/etc and ap_pop_iol_read/write/etc in
the case of option2) which would add these functions to the IOL list.



The promised variation on the APR types.  ALL APR types have a context
associated with them.  Currently, it is not possible to retreive that
context.  It would be possible to put the context into the same type as
the IOL functions, and the context would then be easily accessible.
Example:

_IOL_
ap_context_t *
void *
(*read)
(*write)
(*close)
etc.

This would allow people to scope data the same as the APR type they got
the context from.  For example, if I know I have a peice of data that is
alive only as long as a particular file, I can grab the context from that
file and allocate data out of the context.

Thoughts?

Ryan
_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	




Mime
View raw message