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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
