apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r442492 - /apr/apr/branches/1.2.x/network_io/unix/sockets.c
Date Wed, 20 Sep 2006 11:23:59 GMT
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

Mime
View raw message