lkml.org 
[lkml]   [2008]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Honoring SO_RCVLOWAT in proto_ops.poll methods
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


\
 
 \ /
  Last update: 2008-10-20 06:01    [W:0.115 / U:0.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site