This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: recvfrom + MSG_PEEK = broken?
Am 23.03.2010, 07:24 Uhr, schrieb Charles Wilson:
On 3/22/2010 4:33 PM, Warren Young wrote:
On 3/22/2010 5:03 AM, Corinna Vinschen wrote:
The last time I had problems with MSG_PEEK was back in 2006. Curious
how seldomly it's used, apparently.
Peeking is evil:
http://tangentsoft.net/wskfaq/newbie.html#peeking
The extra kernel context switch problem isn't Windows-specific, so
peeking should be avoided in all code for that reason alone.
That's all well and good, but I'm not writing new code; I also see no
need to rewrite xinetd from the ground up, as that'd be what it would
take to avoid the use of MSG_PEEK. I'm simply trying to get existing
code, which uses normal POSIX functions in their normal, documented way,
to work properly. recvfrom has a specific, documented POSIX behavior,
and that behavior includes MSG_PEEK. Cygwin's implementation didn't
work before; now it does. That's a plus, no matter what some random
webpage might think about the function.
FWIW, fetchmail has had a Cygwin-specific workaround for a
recvfrom(...MSG_PEEK)/read sequence for ages (since 2001, to be precise).
Perhaps a similar workaround might want to migrate into Cygwin, unless
it's already there (if so, I'd like to know the version so I can make this
workaround depend on the Cygwin version).
The code was originally from Jason Tishler (see URL embedded in the
comment) and is now upstream in socket.c, full reference:
<http://gitorious.org/fetchmail/fetchmail/blobs/master/socket.c> ll.
999ff. currently:
#ifdef __CYGWIN__
/*
* Workaround Microsoft Winsock recv/WSARecv(..., MSG_PEEK) bug.
* See http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html
* for more details.
*/
static ssize_t cygwin_read(int sock, void *buf, size_t count)
{
...
and tries to do a 2nd read to fill "count" in.
Err...sure. "I want to design my networking stack in such a way that it
can't support a specific POSIX call, so I'll blame POSIX"
Rumors have it that WinSock was derived from a BSD stack, and relevant
TCP/IP fingerprints supported that. I never bothered to check though.
--
Matthias Andree
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple