On Wed, Sep 20, 2006 at 12:48:56PM +0200, Mladen Turk wrote: > William A. Rowe, Jr. wrote: > >Joe Orton wrote: > > > >Yes - please do. One aspect of this patch I strongly dislike is the fact > >that it's much less efficient. If the pool associated with the soon-to-be > >allocated apr_socket_t would be destroyed on accept failure (the TYPICAL > >design paradigm) there's no reason to avoid this allocation, and we've > >watched sa buffers grow as the network layer has become richer (e.g. IPV6) > >which makes stack a suboptimal place to place such buffers. > >
"much less efficient" seems a bit strong - the performance difference is a larger stack frame and an additional ~128 byte memcpy which I expect is totally lost in the noise for this function, or have you benchmarked it? > So, either we'll have the Win32 way of doing accept or the unix one. > I personally think that not allocating apr_socket_t if the accept > fails would give the simpler programming interface without > worrying on memory usage, and that would at least allow much > faster non-blocking socket accept without the need to create/destroy > pools on each APR_EAGAIN. As usual what is lacking is any kind of strong API guarantee, just "hey this function uses a pool. good luck out there". If the API guarantee is "may allocate memory on failure" then the fix is bad and should be reverted; the caller will have to do the create/destroy dance anyway so it's needless overhead whether large or small. If the API guarantee is "will not allocate memory on failure" then clearly this fix is necessary. I think this option makes more sense. joe
