apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: cvs commit: apr configure.in
Date Thu, 08 Jul 2004 18:14:11 GMT
--On Thursday, July 8, 2004 8:32 AM +0100 Joe Orton <jorton@redhat.com> 

> Since we know the cleanup does nothing, defining it unnecessarily wastes
> both a few bytes of code size and a few cycles at run-time. e.g. since
> the cleanup is never registered for the non-epoll/kqueue case, running
> apr_pool_cleanup_destroy() will iterate over the whole cleanup list
> looking for it if apr_poll_destroy() is called.

Well, we follow this idiom several other places in APR - see shmem.  (I 
half expect you to go through and rewrite shmem now that I point that out.)

> The "unreal?" poll/select implementations will be used on the majority
> of APR platforms and do *not* currently require a cleanup, no "perhaps"
> about it.  This is just a minor optimisation with minor cleanliness cost
> for the majority of platforms, I don't think it's a big deal.

It's just that we've never gotten around to enabling the platform-specific 
optimizations for the platforms until now.  FreeBSD, Darwin, Linux will 
already hit them with these latest patches.  Eventually, Solaris would too. 
(I bet AIX and HP-UX have similar pollset implementations, but I don't know 
for sure.)  To me, that means the majority of Unix platforms will require a 
cleanup - this means the conditional is going to get really long and messy. 
So, the extra marginal cost on those platforms using the fallback 
implementation is gained back by the ease of maintaining the code by 
reducing how many places we need to define the conditionals.

I realize it's a minor point, but I guess I would have liked to have 
discussion on these changes first.  *shrug*  -- justin

View raw message