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
