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
-
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/
This archive was generated by hypermail 2b29 : Tue Jan 23 2001 - 21:00:18 EST