Date: Wed, 14 Jul 1999 21:09:31 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Tani Hosokawa" <unknown@riverstyx.net> Cc: <chat@FreeBSD.ORG> Subject: RE: Known MMAP() race conditions ... ? Message-ID: <000101bece77$d71c9fc0$021d85d1@youwant.to> In-Reply-To: <Pine.LNX.4.10.9907142023160.2405-100000@avarice.riverstyx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000101bece77$d71c9fc0$021d85d1>