On Fri, 13 Dec 2002, Aaron Bannert wrote: > It looks to me like it's used in conjunction with sendfile > on Linux, and is probably useful for preventing slow starts > on big bursts of data (like a response). I suspect it is > especially useful when each header in the hdtr->headers iovec > is not going to fill a full packet. (Is this thing anything > other than the opposite of TCP_NODELAY?) > > It is one of those things that only helps if you have it and > doesn't hurt if you don't.
The web server doesn't use it to stop slow starts on big bursts of data, because the concept is completely non-portable. That makes the whole thing ludicrous to have in a portable run-time. If the app tries to take advantage of APR_TCP_NODELAY, and they test on Linux or FreeBSD, it will do exactly what they expect. However, if they test on _any_ other platform, it won't. 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? Ryan > > -aaron > > > On Friday, December 13, 2002, at 09:11 AM, <[EMAIL PROTECTED]> wrote: > > > > > This concept is not portable at all as far as I know, so why do we > > expose > > it in our API? My understanding of TCP_NOPUSH is that it is how linux > > implements sendfile. If that is the case, then it should be removed > > from > > our public API, and we should just use it behind the scenes. > > > > If that isn't the case, then can somebody please explain how an > > application that uses APR_TCP_NOPUSH is at all portable? Once that > > flag > > is used, the application will behave differently on many platforms. > > > > I would like to remove that macro later this weekend, so please let me > > know if that will be an issue. > >
