httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: confused child
Date Fri, 19 Dec 1997 18:56:00 GMT
On Fri, 19 Dec 1997, Paul Sutton wrote:

>   My name       In Unix            In NT
>   --------      -----------------  ------------------------------
>   parent        a process          a process
>   master        n/a                a special thread
>   worker        a process (same    a thread 
>                    as "child")
>   child         a process (same    a process, which contains
>                    as "worker")       "master" and "worker" elements
> Perhaps this is too abstract.

No not really, if it helps you or anyone else understand http_main then I
say go for it.  We need to understand it in order to rip it apart and put
it back together in more abstracted pieces :) 

> > The current NT model (SMS) has a single sub-process, and within that
> > multiple threads (and within those a single fiber, but fibers don't
> > apply to 1.x).  But given your description I don't think I understand
> > the current NT model, I'll admit I haven't looked at it hard.
> The NT model is a single thread to do a listen/accept loop, and other
> threads to take the accepted socket and handle it. This is the traditional
> way to do a server on NT. Even with overlapped IO you usually need a
> special thread to handle the incoming connections. 

Oh ok, that's still SMS... cool.  The "dispatch" of connections happens
embedded in model-specific code, so the core of the server doesn't need to
know how it got the socket it's reading/writing.

> > >   parent   -- the parent process, which looks after other processes
> > I call this the "main process".
> Yeah, ok. I missed this name in the document -- its only mentioned in the
> "how do we initialise all of this" section. But I'm happy with it instead
> of parent. It is more obvious in the current NT and Unix cases. However I
> was trying to abstract away from all mentions of process/threads/fibers in
> my naming, just in case we ever get a situation where we (say) want to
> implement the "main process" functionality in a thread, rather than a
> process (I expect most NT servers actually work like this).

Right, this is something to worry about.  I don't think I preclude the
case though where the "main process" is also the only "sub process" -- I
only differentiate between them because it's necessary for initialization
in the models that use fork().

> > >   master   -- the "special" thread which looks after the threads
> > I don't give this a name because it is specific to how a particular
> > processing model is implemented.  But maybe I should give it a name.
> Well its pretty difficult to work with this on NT without a name for it. 
> Incidently, do you think that one Unix _all_ fibers (workers?) will be
> executing identical loops, i.e. no need for a special thread to track
> state, manage connections, do logging or anything like that? 

Not necessarily.  Yes the worker name is good -- it can describe what the
"main loop" dispatches requests to.  I expect the fibers (or threads in
SMS) to be partitioned into groups like:

    group of workers (i.e. protocol handlers)
    group of loggers
    group of ...

There may even be the distinctions:

    group of HTTP workers
    group of proxy HTTP workers
    group of FTP workers

if it seems reasonable.  I do want to be able to support other protocols
out of the same dispatch code.  Essentially I want protocol modules which
only have to call a registration function saying "here's an addr:port
list, some scheduling parms like min/maxspare, please build me a pool of
workers which call my_protocol_handler() whenever there's a new request".

Every so often I get scared this is all too ambitious.


View raw message