On Wed, 1 Sep 2010, Dirk Manske wrote:

> I've verified again. And I've forgotten to switch back from threaded
> resolver to c-ares. And with c-ares it's really fixed, sorry that I didn't
> get that. Only if curl is configured to use threaded resolver I see the
> misbehavior of total timeout in multi-single.

I've committed a few more related fixes this afternoon.

Before I pushed my changes, I tested my code with hiperfifo both using c-ares
and the threaded resolver. I had the server just be 'nc -l -p9999' with a
connect and total timeout for each handle and they seemed to timeout as asked
for.

It'd be great if you can update and run some tests again and see how it seems
to behave for you now.

>> libcurl currently has no way to cancel one of its internal timeouts so if
>> we use a connect timeout at 3 seconds and a global timeout at 10, there are
>> two timeouts set so even if the connect succeeds the first timeout will
>> expire after three seconds.

> Before the connection is etablished there could be only two timeouts
> (resolve,connect) both are gone obsolete after connection. So they could be
> easily removed by expire 0 and set then the total timeout. The timeouts of
> the speed checks are set later. Or have I missed s.t.?

No, that's correct. We _can_ do it like that. I'm however reluctant to do that
because removing all timeouts for a handle unconditionally is a bit harsh and
I'm afraid we'll use another timeout soon enough that shouldn't be cancelled
at that time but then gets cancelled by expire 0.

I think that if we are to remove timeouts while a transfer is in progress, we
should have a dedicated remove-timeouts function that only removes the exact
timeouts we don't want anymore and leave any others that may exist at the
time.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html