apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Date Mon, 16 Dec 2002 12:06:50 GMT
I'd rather see it documented and the issues looked at on the other

It was added as we originally had TCP_CORK and that is Linux only. We detect
whether we have TCP_NOPUSH and try to make the usage as general as
possible - that process should be fixed and improved on :)


----- Original Message -----
From: "Joe Orton" <joe@manyfish.co.uk>
To: <dev@apr.apache.org>
Sent: Friday, December 13, 2002 8:07 PM

> On Fri, Dec 13, 2002 at 10:12:17AM -0800, Ryan Bloom wrote:
> > So, I continue to wonder, how is it useful to have this in a _portable_
> > run-time, when the concept isn't at all portable?
> Will you also be removing threads, IPv6, and all the other stuff which
> isn't implemented on every single platforms APR supports?
> I don't care much about this particular issue, but I don't buy the
> argument: as Aaron said, setting TCP_CORK is a useful optimisation on
> platforms which support it. You can write a portable application which
> uses TCP_CORK if available and doesn't if it's not - just as you can
> write a portable app which can use threads.
> If you drop it from the APR API that just makes it considerably harder
> for people to use the optimisation: they would have write the autoconf
> checks, make their code a mess of ifdefs, call apr_os_sock_get to get
> the fd out, blah blah blah.  I'd wager the end result would be a less
> "portable" application than if the code was in APR, since it leaves more
> things for the app to screw up.
> Having said that, leaving NOPUSH in the API as undocumented as it is
> currently also allows the app to screw up and be unportable, so there's
> an argument for removing it.
> Regards,
> joe

View raw message