"Daniel Stenberg" <daniel-curl_at_haxx.se> said:

> -c is not the short option for --connect-timeout :-) -c is for --cookie-jar!

Danm, isn't there any character available.

> Actually, both timeouts work fine and they only have the name resolve problem
> you mention above (the -m timeout includes the connect timeout). I don't see
> how you can solve this problem *failsafe* with an additional thread that kills
> the first one on timeout. Won't there be a problem with left allocated
> resources?

I think you got my meaning backwards; I meant Curl_resolve() starts a thread
to run the blocking gethostbyname() in (unless name is cached). And then either
use a emulated SIGALRM or poll the thread for expiry, "set.connecttimeout" ?
If timed out, kill the thread. It's not leaking resources contrary to what MSDN says.
alarmfunc() could be used to set a per-connection flag. But not longjmp() on Windows
since that will crash for sure.

I've heard from Guy Harris (Ethereal) that longjmp-ing out of a signal-handler
on *BSD/Mac-OSX isn't safe either. Which makes sense since signals are usually
raised via a separate thread and the thread-id isn't stored in the jmp_buf.

And C99, sec 7.14.1.1 sys this:
  If the signal occurs other than as the result of calling the abort or
  raise function, the behavior is undefined if [...] the signal handler
  calls any function in the standard library other than the abort
  function, the _Exit function, [...]

--gv

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-02-03