On Thu, Jan 18, 2001 at 09:44:57PM +0100, Ingo Molnar wrote:
> why? TCP_CORK is equivalent to MSG_MORE, it's just a different

I thought you agreed it isn't (Linus's example I quoted).

> > Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it
> > isn't setting any socket state, [...]
> 
> well, neither is clearing/setting TCP_CORK ...

clearing/setting TCP_CORK is a stateful opertaion, it changes a socket option.

> > and also because the SIOCPUSH has nothing specific with TCP_CORK, as
> > said it can be useful also to flush the last fragment of data pending
> > in the send queue without having to wait all the unacknowledged data
> > to be acknowledged from the receiver when TCP_NODELAY isn't set.
> 
> huh? in what way does the following:
> 
> {
>         int val = 1;
>         setsockopt(req->sock, IPPROTO_TCP, TCP_CORK,
> 			(char *)&val,sizeof(val));
>         val = 0;
>         setsockopt(req->sock, IPPROTO_TCP, TCP_CORK,
> 			(char *)&val,sizeof(val));
> }
> 
> differ from what you posted. It does the same in my opinion. Maybe we are
> not talking about the same thing?

The above is equivalent to SIOCPUSH _only_ if the caller wasn't using either
TCP_NODELAY or TCP_CORK.

> [this is nitpicking. I'm quite sure all the code uses '1' as the value,
> not 2.]

I'm quite sure too but I will not get suprirsed anymore by getting bugreports
because of such an innocent change ;). Though real reasons are others (I
mentioned the backwards compatibility breakage more as a side note).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/