Re: connect-timeout not working
Date: Fri, 4 Jan 2002 11:37:56 +0100
On Thu, Jan 03, 2002 at 07:06:50PM +0100, Daniel Stenberg wrote:
> On Thu, 3 Jan 2002, Georg Horn wrote:
> The signal based timeout is only used for the name resolving, yes, but that
> is intentional and supposed to work. The connection phase is using
> non-blocking sockets and should never be able to "hang", no matter what the
> remote server decides to do.
So a connect with a non-blocking socket should immediately return with an
errno of EWOULDBLOCK and you can then wait for the connection with select()?
Cool, i always thought, that this non-blocking effect would only be usable
for read()s after a connection has been established...
> > I made a patch that moves the piece of code that restores alarms and
> > signal-handlers behind the connect-phase.
> I understand that this patch make things work, but I don't think it is the
> best fix possible. We want proper timeouts *without* signals, as far as we
> possibly can. Signals should be considered evil all through libcurl.
> Do you have any good way to repeat this problem? Can you figure where it
> hangs? What OS are you experiencing this on?
I'm using a rather old Suse-Linux-6.3 with glibc-2.1.2, but i think that's
not the cause. After looking over it again, i think that it hangs somewhere
during the SSL- handshake, because i get error messages like this:
curl: (35) SSL: error:00000000::lib(0) :func(0) :reason(0)
So the connect() seems to work fine, but it hangs somewhere in the SSL-lib
and never returns. Any idea, how to solve this? Do the ssl-functions have
an option to set a timeout, or should we turn off signals after the dnslookup,
and turn them on again before doing the ssl stuff?
Received on 2002-01-04