Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <sc3592fd.051@prv-mail20.provo.novell.com>
Date: Fri, 04 Jan 2002 11:33:09 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@apr.apache.org>,<trawick@attglobal.net>
Cc: <apr-cvs@apache.org>
Subject: Re: cvs commit: apr/network_io/win32 sockets.c
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

    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.  
    Whether there is more or less total work being done really depends
on where you are spending your time.  In the polling implementations
that I have seen so far, select() is called just to determine if there
is work to do.  If there is, then accept() is called.  It seems that
this might be fine if you have a fairly idle web server.  But if the web
server is busy, calling select() is just an unnecessary step.  It is
more likely that there is always work to do, so why not just accept()
the work and move on.  A non-blocking socket would allow you to do the
work of select() and accept() all at the same time.  Am I wrong in my
thinking here?

Brad

>>> Jeff Trawick <trawick@attglobal.net> Friday, January 04, 2002
10:58:17 AM >>>
bnicholes@apache.org writes:

> bnicholes    02/01/04 09:25:49
> 
>   Modified:    network_io/win32 sockets.c
>   Log:
>   Deferred the memory allocation for the new apr_socket_t until after
the accept()
>   call so that we don't chew up huge chunks of memory when using
non-blocking
>   sockets and also avoiding unnecessary memory allocations on error
conditions.

I wonder:

. what sort of non-broken program would suffer with the code the way
  it used to be?

. isn't there more total work done now on the normal path?

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/ 
             Born in Roswell... married an alien...