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
|