From owner-freebsd-hackers Tue Feb 19 17: 1:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id CE37E37B405 for ; Tue, 19 Feb 2002 17:01:26 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #2) id 16dL8D-00059V-00 (Debian); Wed, 20 Feb 2002 01:01:13 +0000 Date: Wed, 20 Feb 2002 01:01:13 +0000 From: Tony Finch To: Terry Lambert Cc: Alfred Perlstein , Dominic Marks , Kip Macy , Peter Wemm , Mike Silbersack , Hiten Pandya , freebsd-hackers@FreeBSD.ORG Subject: Re: In-Kernel HTTP Server (name preference) Message-ID: <20020220010113.B17928@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3C72A7B8.DD297F4E@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > On SVR4, an attempt to access a non-resident page via a > non-blocking fd will result in a fault for that page > being scheduled, while the call returns to the user > process with an "EWOULDBLOCK". > > A subsequent attempt to read it gets the paged in data, > and then works as expected. > > The poll() call takes note of these outstanding page-in > requests, and uses them to satisfy poll on a readable > condition, so you can e.g. attempt the read, get that it > would block, and then poll on readable on the fd, to > avoid buzz-looping the process. How does it deal with the situation that the machine's working set has exceeded memory? If the web server is dealing with lots of concurrent connections it may have to block in poll() waiting for (say) a thousand pages to be brought in, then in the process of dealing with them after the poll() returns some of the pages may get re-used for something else making read() on a "readable" fd return EWOULDBLOCK again. But on the other hand the OS can't lock the pages in memory until they are read, since passing the fd to poll() isn't a promise to read since this may lead to DOS attacks, or alternatively processes being unexpectedly killed for hitting RLIMIT_MEMLOCK. I can't see a good way of avoiding these semantic problems without changing to a completely different kernel API like KSE. Tony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message