Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[Andrea Arcangeli]

On Thu, Jan 18, 2001 at 10:57:20PM +0100, Ingo Molnar wrote:
> 
> On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
> 
> > > {
> > >         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.
> 
> why? I can restore whatever state i want, the above is just a mechanizm to

This is a possible slow (but userspace based) implementation of SIOCPUSH:

{
	int was_set_tcp_cork, was_set_tcp_nodelay, val

	getsockopt(TCP_CORK, &was_set_tcp_cork)
	if (was_set_tcp_cork)
		val = 0
	else if (!was_set_tcp_nodelay)
		val = 1
	else
		return
		
	setsockopt(TCP_CORK, &val)
	val = !!val
	setsockopt(TCP_CORK, &val)
}

Your one ins't.

BTW, the simmetry between getsockopt/setsockopt further bias how SIOCPUSH
doesn't fit into the setsockopt options but it fits very well into the ioctl
categorty instead. There's simply no state one can return via getsockopt for
the SIOCPUSH functionality. It's not setting any option, it's just doing one
thing that controls the I/O.

Andrea