From owner-freebsd-chat Wed Jul 14 21:13:52 1999 Delivered-To: freebsd-chat@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 0C671154E6 for ; Wed, 14 Jul 1999 21:11:27 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 14 Jul 1999 21:09:32 -0700 From: "David Schwartz" To: "Tani Hosokawa" Cc: Subject: RE: Known MMAP() race conditions ... ? Date: Wed, 14 Jul 1999 21:09:31 -0700 Message-ID: <000101bece77$d71c9fc0$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Pardon my parroting... I'm mostly going to regurgitate what's already been > said on this subject by those more qualified than mysel. Okay. > This has all been bantered about before, but I think the general consensus > was that doing things like that made user-written modules very difficult, > as the callback model is very non-intuitive. I disagree. There's no big deal if some threads do occasionally block. Other threads in the job pool will take over. The real problem is in a one-thread-per-request model, because in that case, if a thread ever blocks, it stalls a whole connection. Any sophisticated program will be non-trivial to add on to. But the beautiful part of a thread pool model is that you can break all the rules, and you'll only affect the code minimally. If you have to block, fine, you have to block. It's not ideal, but it's not a disaster either. > In addition, using a > select/poll model leaves you open to major screwups, like if your disk I/O > blocks unexpectedly, you'll hang the entire process, because there's no > asynchronous I/O. Umm, no. In the model I described, _all_ I/O is asynchronous. If your disk I/O blocks unexpectedly, that particular job will not complete until the I/O finishes, but it couldn't complete anyway. You won't even stall that request, unless the I/O was required to complete the request. (Obviously, a page get in a web server can't complete until you read in the page.) DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message