Date: Sat, 19 Jun 1999 02:18:18 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: Apache Developers <new-httpd@apache.org>
Subject: Re: Async server questions
In-Reply-To: <19990619021846.A13784@io.com>
Message-ID: <Pine.LNX.3.96dg4.990619021002.27639m-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Sat, 19 Jun 1999, Manoj Kasichainula wrote:

> A couple of questions while I was pondering this async server stuff.
> 
> 1. Why is a user thread or MxN thread system not a good enough
> replacement for all of the poll-select-accept event looping? Is it the
> extra RAM from thread stacks? Do user thread libraries typically limit
> the number of threads available?

They may be good enough... but they're not available everywhere -- linux
doesn't have one yet (well yeah it has NSPR, and you can build NSPR in MxN
mode... dunno if anyone has done that on linux yet though).

But there is definately extra RAM from the stacks.  My main thought with
that model is to handle the slow clients loading large files.  I want to
keep the memory footprint as small as possible.

A userland-only thread library won't benefit as much from the hybrid I'm
working on.  But a kernel-only thread setup (i.e. linux) will benefit
more... because not only do you save the userland stack, but you save the
unswappable kernel memory associated with the task slot. 

> 2. Which thread model? I can think of two: the Flash model with a
> single event thread and lots of helper threads (like your earlier
> select-thread-hybrid patch worked), and a Zeuslike model, but with
> multiple event loop threads.

I'll be doing the select-thread-hybrid thing again...

It really can vary from platform to platform depending on what's
available. 

Dean