Date: Wed, 14 Jul 1999 21:31:38 -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: <000301bece7a$ededf700$021d85d1@youwant.to> In-Reply-To: <Pine.LNX.4.10.9907142113280.2405-100000@avarice.riverstyx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Because there are other threads that will pick up other jobs. You only need to stall processing on that connection if the that particular job must be completed before the connection can proceed. If the job is, for example, a logging job, it will stall nothing. If it's a resolver job, you can design it to stall only until that information is needed. Since threads handle jobs and not connections, a stalled thread will stall a job, not a connection. Unless the job has to be completed for the connection to continue, stalling a job will not stall a 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. > > 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 would not change. However, code that blocked would result in extra threads being required. In the worst possible case, where everything was badly designed and required an extra thread, you'd be back to one thread per connection. So you are starting off with my worst case. > 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. And the overhead of managing so many threads. And the affect that has on the caches. And the effect that has on the schedular. And the memory all their stacks eat up. And on, and on, and on. > 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. This is the same in the model I'm talking about, just replace 'request' with 'job'. > > > 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. No, no. You don't 'poll' on disk I/O. You have a job that issues a disk I/O request. The thread performing that request, and thus that job, is blocked on the I/O. But the connection is not blocked, unless it requires the I/O. In other words, you only block when you absolutely need the data in order to continue processing that one job. > So, eventually you're going to have to do a read, and if you hang then, > all jobs stall. No, the current job stalls. How does one job stalling affect the others? Remember, you have a poll of threads (whose size is dynamically adjusted) pulling jobs out of the pool. 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?000301bece7a$ededf700$021d85d1>