Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Feb 2002 17:54:31 +0000
From:      Dominic Marks <dominic_marks@btinternet.com>
To:        Kip Macy <kmacy@netapp.com>
Cc:        Peter Wemm <peter@wemm.org>, Mike Silbersack <silby@silby.com>, Hiten Pandya <hiten@uk.FreeBSD.org>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: In-Kernel HTTP Server (name preference)
Message-ID:  <20020219175431.A12535@host213-123-131-110.in-addr.bto>
In-Reply-To: <Pine.GSO.4.10.10202190914510.25289-100000@cranford>; from kmacy@netapp.com on Tue, Feb 19, 2002 at 09:19:56AM -0800
References:  <20020219092058.A78717@host213-123-131-110.in-addr.bto> <Pine.GSO.4.10.10202190914510.25289-100000@cranford>

next in thread | previous in thread | raw e-mail | index | archive | help
Hey,

On Tue, Feb 19, 2002 at 09:19:56AM -0800, Kip Macy wrote:
> > Apache will switch to this method at some point. I really can't
> > understand why they went with that complicated pre-forking stuff.
> > Using non-blockijng I/O is just not that hard."
> 
> As mentioned previously, due to the blocking semantics of file I/O on unix,
> single process servers will only provide peak throughput if everything is
> resident. By pre-forking, data can continued to be served if one process blocks
> on file I/O. Apache already handles multiple connections within a process, so
> it does something like this already.

Yes.. but if your using non-blocking IO for both the disc and network
read/writes, this no longer applies. If I understand correctly in
normal operation a server like tHttpd simply blocks on kevent() and
when a descriptor becomes available for servicing it handles this
occurance, or occurances since a single kevent() call can return more
than a single event and then goes back to blocking. Reads and writes
don't block if they don't complete, you simply get another event when
the descriptor becomes available again.

Am I wrong?

> 			-Kip
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
Dominic

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020219175431.A12535>