Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Wed, 15 Aug 2001 09:50:34 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: 1.3.2: Cygwin && UDP && O_NONBLOCK Message-ID: <20010815095034.A6745@cygbert.vinschen.de> Mail-Followup-To: cygwin AT cygwin DOT com References: <8F23E55D511AD5119A6800D0B76FDDE1CA302A AT cpex3 DOT channelpoint DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8F23E55D511AD5119A6800D0B76FDDE1CA302A@cpex3.channelpoint.com>; from troy.noble@channelpoint.com on Tue, Aug 14, 2001 at 01:54:27PM -0600 On Tue, Aug 14, 2001 at 01:54:27PM -0600, Troy Noble wrote: > Roderick, > > Unless I misunderstood entirely, I think you've found a bug. > > I got the same blocking behavior you described when testing > (after fixing many of the same things that Keith > described in his mail). And it does appear to be inconsistent > with behavior on Linux for the same program as you noted. > > Looks like there was a fix for some code related to setting up the > non-blocking behavior in fhandler_socket.cc:fctl on Aug 13, 2001 > so the flags are set properly now, but the recvfrom appears not > to be checking for the non-blocking flag. I updated my src tree > from CVS today and tested, and it still exhibits the blocking > behavior you describe. > > The problem appears to be the wait for an event at net.cc:93 > which looks like: > > switch (WSAWaitForMultipleEvents(2, ev, FALSE, WSA_INFINITE, FALSE)) > > There seem to be at least two ways to fix it, otherwise I'd just > submit a patch. But I don't know that I understand the philosopy > entirely, so it'd be best to defer to Corinna's better judgement. > > It seems to me in net.cc:recvfrom one of the following > needs to happen: > > 1. if ((h->get_flags() & O_NONBLOCK_MASK) > || !(ovr = wsock_evt.prepare ())) > { > ... > > which would cause behavior to revert to Winsock 1.1's > recvfrom which appears to do the right thing, at least in > my minimal testing. Thanks for tracking that down. I changed the code to use your version 1 (fallback to winsock1) in case of nonblocking sockets. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/