From dev-return-13813-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Feb 22 17:41:11 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 822 invoked from network); 22 Feb 2005 17:41:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 22 Feb 2005 17:41:11 -0000 Received: (qmail 90799 invoked by uid 500); 22 Feb 2005 17:41:09 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 90768 invoked by uid 500); 22 Feb 2005 17:41:09 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 90755 invoked by uid 99); 22 Feb 2005 17:41:09 -0000 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=DATE_IN_PAST_06_12,FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net) (204.127.202.64) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 22 Feb 2005 09:41:07 -0800 Received: from slowhog.ztune.net (c-24-6-11-151.client.comcast.net[24.6.11.151]) by comcast.net (sccrmhc13) with ESMTP id <2005022217410401600sfvije>; Tue, 22 Feb 2005 17:41:04 +0000 Received: from henryjen by slowhog.ztune.net with local (Exim 3.36 #1 (Debian)) id 1D3TzM-0003T6-00 for ; Mon, 21 Feb 2005 22:57:44 -0800 Date: Mon, 21 Feb 2005 22:57:44 -0800 To: dev@apr.apache.org Subject: Re: [Patch] - apr_recvfrom on Win32 returns 730022 instead of blocking as expected Message-ID: <20050222065744.GA13329@linuxfan.com> References: <1108781139.3065.13.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Henry Jen X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Sun, Feb 20, 2005 at 06:24:17AM -0500, Jeff Trawick wrote: > On Fri, 18 Feb 2005 18:45:39 -0800, Henry Jen wrote: > > > Attached patch fix a bug on Win32, if call apr_recvfrom() when no one > > write to that addr:port, the call returns 730022(WSAEINVAL) instead of > > blocking as expected. > > > > The reason is that the from->salen was not initialized properly. The > > patch fix the problem. > > I'm trying to figure out why that field isn't yet set when you call > apr_recvfrom(). > Hmm, I am using a apr_sockaddr_t from stack without initialize it first. That's what went wrong. I should have initialized it first. However, I think to reset the value maybe not a bad idea as that's an input/output field. > First you call apr_socket_create(), which calls apr_socket_create_ex(). > apr_socket_create_ex() calls set_socket_vars(*new, family, type, protocol). > set_socket_vars() calls apr_sockaddr_vars_set(sock->remote_addr, family, 0). > apr_sockaddr_vars_set() will set addr->salen to sizeof(struct sockaddr_in). > This is not about apr_socket_t, it's apr_sockaddr_t(first parameter) for calling apr_socket_recvfrom. Unless you are suggesting me to use the remote_addr from apr_socket_t. If that's the idea, why do we need to passed in the apr_sockaddr_t in the first place? > Can you tell me where this breaks in your situation? (i.e., why > didn't apr_sockaddr_vars_set() set from->salen to the proper value > before you called apr_socket_recvfrom()?) > I use an apr_sockaddr_t from stack without initialize it. :-) > Thanks, > Thank you for looking into it. :-) Henry