Re: Honoring SO_RCVLOWAT in proto_ops.poll methods

From: swivel
Date: Sun Oct 19 2008 - 23:58:31 EST

On Mon, Oct 13, 2008 at 02:58:16AM -0700, David Miller wrote:
> From: swivel@xxxxxxxxxxxxxxxxxxxxxxxx
> 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()

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?

Vito Caputo
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at