httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: layered i/o and coprocesses
Date Mon, 25 May 1998 13:43:18 GMT
Dean Gaudet wrote:
> 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".

This is exactly what was under the hood of RST's threading. "Some
creativity" means, on some systems, actually hacking the jmp_buf - SCO,
for example, detects that you are trying to pull a fast one if you do it
the cunning way.

And yeah, when we were discussing all this a year or two ago, it was
precisely the nasty "inside-outness" of the simple model that I was
trying to avoid (i.e. one thread write()s and the other read()s as if
there were a pipe between them. This is not the most efficient model,
but it sure as hell opens it up to more programmers...). I'd suggest we
support both - I seem to remember it is possible to write the "threaded
pipe" as a layer/thread itself, which can be inserted into layered i/o
(sort of) when needed and left out if people can be bothered to write it
the hard way. Hmmm ... not sure I'm expressing myself very clearly here.
Let me know if this reads like Greek!



Ben Laurie            |Phone: +44 (181) 735 0686|  Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|
and Technical Director|Email: |
A.L. Digital Ltd,     |Apache-SSL author
London, England.      |"Apache: TDG"

View raw message