Date: Tue, 19 Feb 2002 10:00:04 -0800 From: Alfred Perlstein <bright@mu.org> To: Dominic Marks <dominic_marks@btinternet.com> Cc: Kip Macy <kmacy@netapp.com>, 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: <20020219180004.GO12136@elvis.mu.org> In-Reply-To: <20020219175431.A12535@host213-123-131-110.in-addr.bto> References: <20020219092058.A78717@host213-123-131-110.in-addr.bto> <Pine.GSO.4.10.10202190914510.25289-100000@cranford> <20020219175431.A12535@host213-123-131-110.in-addr.bto>
next in thread | previous in thread | raw e-mail | index | archive | help
* Dominic Marks <dominic_marks@btinternet.com> [020219 09:53] wrote: > 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? Yes, you are wrong. Disk IO can't be done in a non-blocking manner. If the kernel doesn't have the portion of the file you wish to read in the buffer cache then the process will block waiting. There is simply nothing you can do about this other than to offload that blocking into another process context via kernel threads, posix aio or kses. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ 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?20020219180004.GO12136>