Date: Wed, 20 Feb 2002 01:01:13 +0000 From: Tony Finch <dot@dotat.at> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <bright@mu.org>, Dominic Marks <dominic_marks@btinternet.com>, 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: <20020220010113.B17928@chiark.greenend.org.uk> In-Reply-To: <3C72A7B8.DD297F4E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert2@mindspring.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020220010113.B17928>