httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: PR & 1.1b1
Date Tue, 19 Mar 1996 23:06:04 GMT
In reply to Ben Laurie who said
> 
> I think we have a basic misunderstanding here. When I say singlethreading, I
> don't mean handle one request then handle the next. I mean do a lot of
> select()ing, partial reads, partial writes and so forth. So requests are
> handled concurrently but without the use of threads.

Ahh, the light suddenly comes on. Yeah ok, I can see how a single-threaded
process would work now.

> In this model, time consuming processes are usually handled by subprocesses,
> so they don't delay the main process. Of course, all these partial reads and
> writes mean that each "thread" (not a real thread, remember) has to carry a
> lot of state with it. On the other hand, it generally doesn't need to have any
> truck with semaphores and so forth.
> 
> The completely different mode of execution also means a different API (more
> along the lines of "I'm ready to send something, have you got anything to
> send?" rather than "Send this when you can (and block me in the meantime)").
> Inside out, in short.

(For this discussion I use thread to mean a thread of control which could
actually be implemented in a number of ways.)

There will always be a control thread, this is either the parent in a
forking system (or a LWP thread implementation) or in the
single-threaded implementation you're talking about it will be the
internal scheduling loop. Now, regardless of how this control thread
is implemented the protocol API will be the same from the protocol handler's
point of view. The main control thread would have to receive enough data to
determine the protocol handler to call. In a forked model it would then
pass the request to a child, in a single-threaded model it would queue
the request on that particular handlers queue. In both cases, as far as the
protocol handler is concerned it will receive a complete request so the
API would be the same for both i.e. register a handler for passing requests
to. It's the main control thread that would "hold" the request until it
was OK to pass it to the protocol handler. The converse works in the same
way, when a protocol handler has a reply to send it passes a completed reply
to the "transmit" routine which in a forked model will send the data down the
socket and in a single-threaded model will put the reply on a transmit queue.

I'd really like to see the API, some of this is similar to the protocol
abstraction in BSD networking code.

> As to what the API has to do - I'm not avoiding the question, just deferring
> it, as David Robinson and I pretty much thrashed that out already, I just have
> to find the document...

Ok, I guess the answer to my question is it's already done and implementation
is an issue, you've just gone and lost it :-) When you find it let me know.

> Interesting how C++'s biggest detractors are those who haven't learnt it
> properly. I defy you to produce a neat equivalent of a pure virtual function
> or an overloaded function in C. Operators, of course, you can forget.

I guess it's a bit like why I hate Macs, I *like* to be be able to see what's
going on under the hood and if I need a virtual function then I'm quite at
home dealing with pointers. OO programming is a methodology at the end of
the day.

> I do agree with your suspicion. I might write a C++ wrapper instead, so those
> who can do C++ can use it.

That's a reasonable idea.

-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

Mime
View raw message