httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@eu.c2.net>
Subject Re: confused child
Date Fri, 19 Dec 1997 14:32:35 GMT
On Fri, 12 Dec 1997, Dean Gaudet wrote:
> On Fri, 12 Dec 1997, Paul Sutton wrote:
> > We use "child" two mean different things in Unix and NT. This can be
> > confusing. 
> 
> Yep.
> 
> You should look at the terminology I proposed for the 2.0 process models.
> <http://www.arctic.org/~dgaudet/apache/2.0/process-model> and tell me
> where I've goofed.

Hey, I don't think there is anything wrong with your naming scheme. I was
thinking of my naming as more of an extension or (even more of) an
abstraction. So I defined functionality for the parent, master, worker and
child without defining whether that functionality was provided by a
process, thread or fiber. So, taking the Unix and NT models (MSS, SMS) we
have:

  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.

> 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. 

> >   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).

> >   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? 

> >   worker   -- a thread which actually does the request processing
> I call these fibers.  But in this case, there is a one-to-one mapping
> between fibers and threads.  i.e. we're not using fibers at all.

Yeah, fibers is fine, but has a specific meaning (in Win32 anyway),
whereas I was trying to be abstract here. In particular, in the case of
current Unix (and the MSS model in general), the "worker" is identical to
the "child".

//pcs




Mime
View raw message