Re: Honoring SO_RCVLOWAT in proto_ops.poll methods

[swivel@shells.gnugeneration.com]

On Mon, Oct 13, 2008 at 02:58:16AM -0700, David Miller wrote:
> From: swivel@shells.gnugeneration.com
> Date: Mon, 13 Oct 2008 03:32:14 -0500
> 
> > I'm using the pseudo-blocking recv() behavior achieved with SO_RCVTIMEO.
> > Thus my app expects recv() to block until SO_RCVLOWAT is met or SO_RCVTIMEO
> > expired.
> 
> But if you poll() properly, you'll never call recv() unless the amount
> of bytes you want are there.
> 
> And since I fixed poll()'s handling of SO_RCVLOWAT it should mostly
> work.

The app already has a kludge in place to work around the current kernel
with broken poll() and recv() with regards to SO_RCVLOWAT.

It's less than ideal but 'mostly works', so I'm already at that point...
Doesn't really make sense to me to rewrite the kludge to depend on a
very modern kernel without even having it be able to use recv()
properly.

I just hope we can have recv() block with MSG_PEEK when SO_RCVLOWAT is
>1 in the near future.  My goal was next time I get around to doing a
dist-upgrade the new kernel would have both poll and recv fixed and I
could disable the kludge.

>From what I can see the recv() MSG_PEEK fix is trivial anyways, why not
fix it?

Thanks,
Vito Caputo