httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject layered i/o and coprocesses
Date Mon, 25 May 1998 07:25:06 GMT
Another thing which may have been obvious to others but only occured to me
recently... (hey I was doing a lot of hiking, lots of time to think).

It's not trivial to turn mod_include into a filter.  mod_include is
written by assuming that it is the only thread of control, it's written in
a serial programming model.  That's fine, it's way easier to understand
that way.  But when you try to turn it into a filter you realise that you
need some way to "block" waiting for the writer to feed it more data, and
some way to "block" waiting for the reader to empty its buffers... 

One way to do this is to implement a layer such as mod_include in another
thread and just flip back and forth between threads as needed.  This is
typically called "coprocessing" and can actually be done with a lot less
overhead... but we should probably just start off doing it as threads and
optimize it to coprocessing later. 

I did this stuff for a C preprocessor prototype at one point... we wanted
to write the preprocessor as if it were a single threaded process in a
pipeline, but we were working under DOS where multiprocessing pipelines
don't exist.  The compiler was also written as if it were the single
thread of control.  When the compiler's input routine emptied its buffer,
it would longjmp() into the preprocessor's "output" routine.  Then the
preprocessor would be in control, and eventually would fill its output
buffer, and longjmp() back to the compiler's input routine.  Neither of
them really knew the longjmp() was there, it was as if they were blocked
reading or writing a pipe.  It requires some creativity to get the first
setjmp()s done to initialize the "processes". 

Dean



Mime
View raw message