"Brad Nicholes" <[EMAIL PROTECTED]> 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
growth.
> 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 | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
