httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: layered i/o and coprocesses
Date Tue, 26 May 1998 01:03:30 GMT
The reason I was thinking of co-processes is that they have the potential
to be faster than threads, depends on the threads implementation though...
but I've been trying to convince myself to stop thinking in such detail
about performance and just look at benchmarks to decide what needs
tweaking :)

Dean

On Mon, 25 May 1998, Ben Hyde wrote:

> >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.
> ...
> >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"
> ..
> > ..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()...
> >Dean
> 
> Either you swallow the whole nine yards of threads or
> you end up building lots of things that mimic them.  The mimics are
> usually much faster and confuse the hell out of your maintainers,
> while the "threads are my friend" coding style leads to cussing at
> the OS and an awful lot more threads than you ever expected.  For
> example multiple threads working on a single request.  - ben
> 
> 
> 


Mime
View raw message