On Thu, 3 Jan 2002, Georg Horn wrote:

> Just found out, that the timouts when connecting to a server did not work
> correctly. As in earlier versions (where system calls where restarted after
> signals) curl seems to hang "for ever". So i examined the sources and found
> out, that in url.c a timer is set with alarm() before resolving the server
> name, but is switched off again after nameresolving, so that curl may hang
> for a long time in the following connect.

Uh, well. Thanks for your findings and patch.

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.

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

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/