Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jul 1999 23:39:38 -0700 (PDT)
From:      Tani Hosokawa <unknown@riverstyx.net>
To:        David Schwartz <davids@webmaster.com>
Cc:        chat@FreeBSD.ORG
Subject:   RE: Known MMAP() race conditions ... ?
Message-ID:  <Pine.LNX.4.10.9907142334490.4426-100000@avarice.riverstyx.net>
In-Reply-To: <000301bece7a$ededf700$021d85d1@youwant.to>

next in thread | previous in thread | raw e-mail | index | archive | help
I may be out of my depth here.  However, that doesn't in any way mean that

a) kernel threads are bad

b) software shouldn't use > 300 threads

c) that FreeBSD development should preclude software from operating
efficiently just because a particular paradigm isn't believed to be
optimal.

This only lends credence to the fact that one OS can't do it all.  If
other OS decide to put more effort into threads (or, if FreeBSD remains
below par comparitively), then in the future when Apache is threaded in
the public releases, then those other OS will be a better platform for
webserving under Apache.  This will still leave FreeBSD as the undisputed
champion of, for example, FTP serving.  And QNX for embedded systems.
Etc.

On Wed, 14 Jul 1999, David Schwartz wrote:

> > 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'.
> 
> > 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.

---
tani hosokawa
river styx internet




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?Pine.LNX.4.10.9907142334490.4426-100000>