httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Nicholls <>
Subject Re: [PATCH] win32/sockets.c - remove select in connect routine
Date Wed, 20 Sep 2000 18:13:58 GMT

Jeff Trawick wrote:

> Gregory Nicholls <> writes:
> >  This patch removes the select from the win32/sockets.c connect routine. It will
now permit a
> > non-blocking connect.
> I started playing with your patch and ended up with the patch below.
> In my patch:
> . I modified your Win32 apr_connect() and the existing Unix
> apr_connect() to set some stuff before returning from apr_connect()
> after a non-blocking connect(); these may not be required as long as
> we force the app to call apr_connect() again after finding out that
> connect() is finished

Oh bugger ...  you're right. I had the local_port and local_interface stuff set in an earlier
version and forgot to
do it in the patch <sigh> mea culpa.

> . 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 ??

> . 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
as well.

> 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
client and see what pops up.

View raw message