Messages in this thread | | | From | swivel@shells ... | Date | Sun, 19 Oct 2008 22:58:19 -0500 | Subject | Re: 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
| |