apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/network_io/win32 sockets.c
Date Fri, 04 Jan 2002 18:58:25 GMT
"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 any
> other error condition.  Since we can't dictate how APR or apr_accept()
> will be used, don't we have to allow for all reasonable possibilities? 
> 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 depends
> 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