From owner-freebsd-chat Wed Jul 14 21:24:25 1999 Delivered-To: freebsd-chat@freebsd.org Received: from avarice.riverstyx.net (hq-port-97.harbour-dhcp-pool.infinetgroup.com [207.23.37.97]) by hub.freebsd.org (Postfix) with ESMTP id EB10814D2F for ; Wed, 14 Jul 1999 21:24:20 -0700 (PDT) (envelope-from unknown@riverstyx.net) Received: from avarice (unknown@avarice [207.23.37.97]) by avarice.riverstyx.net (8.9.3/8.9.3) with ESMTP id VAA03488; Wed, 14 Jul 1999 21:23:07 -0700 Date: Wed, 14 Jul 1999 21:23:07 -0700 (PDT) From: Tani Hosokawa To: David Schwartz Cc: chat@FreeBSD.ORG Subject: RE: Known MMAP() race conditions ... ? In-Reply-To: <000101bece77$d71c9fc0$021d85d1@youwant.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 14 Jul 1999, David Schwartz wrote: > > 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. If a thread is blocked, how will that connection continue anyway? The webserver doesn't have any information to send to the client in that case. > 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. As it currently stands, Apache is trivial to add on to. Anyone with a month's worth of programming knowledge can write major additions to the webserver through its module interface. This is because there are several layers of handlers for each phase of the system, which can have additional handlers attached almost anywhere. This is great in a one-thread-per-request system, because you can have arbitrarily complex handlers which won't adversely affect the other requests in progress, aside from the proportional decrease in available CPU. Any one request in its special handler phase can spin for as long as it needs, since the kernel will take care of assigning timeslices to the other requests being processed. > > 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.) How? I wasn't aware that you can poll on disk I/O. In a perfect world, there's asynchronous disk I/O, but last I checked all those aio_* functions weren't implemented everywhere. So, eventually you're going to have to do a read, and if you hang then, all jobs stall. --- tani hosokawa river styx internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message