On Mar 22 10:56, Charles Wilson wrote: > On 3/22/2010 7:03 AM, Corinna Vinschen wrote: > > On Mar 22 02:04, Charles Wilson wrote: > >> I've been tracking down a problem in xinetd. It appears to be an issue > >> with using MSG_PEEK in recvfrom() on UDP sockets. > > > > Yes, that's a bug in Cygwin. The socket event handling got messed up > > when MSG_PEEK was used. I fixed that in CVS so it will be in 1.7.2. > > Confirmed: fixes both my testcase, and the error in xinetd. Thanks for > the quick turnaround! I was about ready to pull my hair out on this
Sure. I'm glad I had a simple testcase for a socket problem. If only somebody would come up with an equally simple testcase for the rsync problem... > > The last time I had problems with MSG_PEEK was back in 2006. Curious > > how seldomly it's used, apparently. > > Well, it didn't appear to cause a problem in xinetd wrt TCP connections, > only UDP. That may explain why I didn't see problems in TCP connections. Apparently there's a difference in event handling between TCP and UDP. For instance, with UDP, if you call recv as you did, with a one byte buffer but more than one bytes ready to read, the event handling notices an FD_READ event just fine, but then the call to WSARecv returns with error(!) and WSAGetLastError() set to WSAEMSGSIZE. For POSIX compatibility Cygwin has to turn this into a successful call with 1 byte read. The next recv call then does not get another FD_READ event, even though the previous call with MSG_PEEK didn't empty the internal recv buffer. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
