Skip site navigation (1)Skip section navigation (2)
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 ... ?
Message-ID:  <>
In-Reply-To: <000101bece77$d71c9fc0$>

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.

> 	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
with "unsubscribe freebsd-chat" in the body of the message

Want to link to this message? Use this URL: <>