apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: apr/network_io/win32 sockets.c
Date Fri, 04 Jan 2002 19:45:50 GMT
    Well, "reasonable" is a very subjective word (which is why I used
it) :)  I have a version of the NetWare MPM which I plan on checking in
that implements a non-blocking accept loop rather than using select() or
apr_poll() to poll the socket.  On an idle web server accept() will be
called (and don't be freaked out by this) 600,000+ times a second.  On a
busy server every call to accept() returns with work to do so there is
essentially no wasted cycles.  In reality I have just shifted the
polling work from a call to select() with a timeout value to my accept()
polling loop where I have more control.  Calling select() with a timeout
value is just doing the same thing.  It has to constantly check the
work-to-do bit just like a non-blocking accept() call does.  If accept()
is called and there is no work to do, then EWOULDBLOCK is returned, the
MPM yields the processor and everybody is happy.  If there is work to
do, then I just avoided checking the work-to-do bit once in select()
(along with whatever else it does) and repeating the check in accept(). 
I just accept() the work and go.  The key is making sure that you yield
the processor so that the accept() thread doesn't become a CPU hog.
    The problem with apr_accept() and memory pools is that you give it
a memory pool to allocate the new socket structure from.  The pool isn't
cleared until after a successful connection is returned by apr_accept()
and the request has been satisfied.  Therefore, unless you are clearing
the pool after every call to apr_accept() (successfull or not) the pool
that you passed to apr_accept() will continue to grow.  At 600,000+ plus
times a second, it doesn't take long to suck your system dry.  This is
the kind of bug that we should be trying *not* to inflict on an
unknowing APR developer.  They would never know that calling
apr_accept() with a non-blocking socket was causing their machine to
consume huge amount of memory unless they knew to look at the APR source
and study it.  Just because we may think that calling apr_accept()
600,000+ times a second is unreasonable, doesn't mean that other APR
developers do.


>>> Jeff Trawick <trawick@attglobal.net> Friday, January 04, 2002
11:58:25 AM >>>
"Brad Nicholes" <BNICHOLES@novell.com> writes:

>     Basically the way it was before prevented apr_accept() from ever
> being called on a non-blocking socket without chewing up a chunk of
> memory the sizeof(apr_socket_t) everytime it got an EWOULDBLOCK or
> other error condition.  Since we can't dictate how APR or
> will be used, don't we have to allow for all reasonable
> If apr_accept() is called on a non-blocking socket multiple times
> resulting in an EWOULDBLOCK, the memory would not be freed until the
> pool is cleared which usually happens much later.  

So for a reasonable program, how many times would we call accept and
get EWOULDBLOCK before we get a real connection?

I'd say that a reasonable program wouldn't call it too many times :)
(though maybe the legitimate scenario is when we get ECONNRESET
infinite times due to some bad boy dropping connections before we can
pick them up from the kernel; but see the next point).

For a reasonable program, to avoid storage growth, we require a new
pool to be used for the connection returned by accept and cleaned up
(e.g., apr_pool_clear()-ed) at the appropriate time by the app.
Wouldn't that handle cleaning up after any accept errors?

For pools in general, I suspect that we're not too clear on how the
app has to manage pools (e.g., pool per connection) to avoid storage

>     Whether there is more or less total work being done really
> on where you are spending your time. 

I meant just within apr_accept().  There is extra logic to copy a
sockaddr.  Not a big deal.

Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message