Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
To: new-httpd@apache.org
Subject: Re: [PATCH] win32/sockets.c - remove select in connect routine
References: <39C258B5.A0067F3E@level8.com>
 <m3bsxplcnk.fsf@adsl-77-241-65.rdu.bellsouth.net>
 <39C27BCD.4A7DC5AD@level8.com> <39C27FA4.5A475E7A@level8.com>
 <39C284AA.CD434AB5@level8.com>
 <m3em2fkppr.fsf@adsl-77-241-65.rdu.bellsouth.net>
 <39C8FE66.52E9F010@level8.com>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 20 Sep 2000 14:49:38 -0400
In-Reply-To: Gregory Nicholls's message of "Wed, 20 Sep 2000 14:13:58 -0400"
Message-ID: <m3bsxilwzh.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 49

Gregory Nicholls <gnicholls@level8.com> writes:

> Jeff Trawick wrote:
> 
> > . I modified the client test program to wait for the connect to
> > complete, and then call apr_connect() again to find out what happened
> 
> This shouldn't be necessary. AFAIK when the socket is available for writing the connect is
> complete. What's
> the second call telling us ??

We don't know whether or not the connect was successful.  On Unix, it
is normal to call connect() again once select() pops; the retcode from
connect() tells us whether or not the connection was established.

> > . I modified (kludged) unix/canonerr.c to map WSAEWOULDBLOCK to
> > APR_EAGAIN; connect() on Win32 returns WSAEWOULDBLOCK in the
> > non-blocking case
> 
> See a previous note where I posted a version of canonerr.c for Win32 that has this and a few others
> as well.

I'm not eager to mess with error codes, so I was testing with a
minimal set of changes.  Besides, Ryan said he was going to handle
your canonerr.c patch :)

> > With my patch, the client test program is broken when it does a
> > non-blocking apr_connect() on Win32.  I try to use apr_poll() to find
> > out when the connect is done, but apr_poll() doesn't return when
> > the connect succeeds/fails.  Maybe I need to pass a different flag?
> > Maybe it just won't work this way on Win32?  This needs more
> > research.
> >
> > In your testing, what did you do to find out when the connect() is
> > done?  That is the missing piece.
> 
> Well all I did was issue a select() with that socket in the write set. I confess I didn't use the
> apr_poll() routine
> so perhaps there's something odd in there. I'll have a bit of a look at the poll routine and the
> client and see what pops up.

Good...  Google told me I could wait for the FD_EVENT event on the
socket to find out when the connect is done, but I don't see how that
fits into the apr_poll() abstraction.

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...