On Mon, 30 Aug 2010, Dirk Manske wrote:

> Sorry, that fixes nothing. The timeouts with multi-single had worked before
> already. Because it's really polling not event driven.

It did fix something, but quite clearly not nearly enough! ;-)

> The second expire also overwrites the first one (if connecttimeout<timeout).

That may be what the sympthom looks like but it isn't exactly what happens
under the hood. libcurl now stores all timeouts set, so it never overwrites
the previous one when you set a new one. It keeps them in a sorted list.

The main problem was that it didn't properly bring in the next timeout in the
list when the first expired. There was also some additional minor mistake in
the list/splay handling. I believe I have fixed these problems now.

To repeat and repair the timeouts, I've used a version of multi-single.c with
a regular timeout at 7 seconds and a connect timeout at 4, and when I connect
to a plain "nc -l -p 9999" session I can see the timeout values first (after
the initial 1ms timeout) show a countdown for the connect timeout to then move
over to the total timeout (with 3 seconds left). It then exits at 7 seconds
pretty accurately.

Please have another try with my recent commit and see how it looks for you
now!

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