It may be that the resolving library detects EINTR and retries.

If so, probably the only way out is with siglongjump, which may not be
entirely platform independent.

Take these comments with a grain of salt, because I haven't read any of the
relevant code.

At 08:26 10/06/2002 +0200, Daniel Stenberg wrote:
>Hey skilled people!
>
>We've been through this before, I know. I thought we solved the problems long
>ago, but no. We have a problem with curl not timing out properly on name
>lookups. The SIGALRM is not properly stopping the operation.
>
>I tried it just now on both Linux i686 and on Solaris 2.7, and neither of
>them did return after the given timeout time when the name didn't resolve
>quickly enough:
>
> $ curl -m5 [host]
>
>The host in my test is always taking a long time and never succeeds to
>resolve. It just don't return failure after 5 seconds. It takes a lot longer.
>
>So, how is this *supposed* to work?
>
> On line lib/url.c:2206 the section that sets up the signal handler starts.
> It sets the signal without SA_RESTART to prevent system calls from getting
> restarted when the signal handler function returns.
>
> On line lib/url.c:2231 alarm() is called.
>
> On line lib/url.c:2253 we call Curl_resolv() that very quickly calls the
> DNS resolve function and there it sits...
>
> [if I add some silly output in the signal handler, I can see it get written
> and then continue waiting...]
>
> ... until it times out and then returns a failure code all the way back to
> the libcurl user.
>
>What do I need to do to make the alarm() abort the name lookup?
>
>--
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -
>http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
Received on 2002-06-10