On Fri, 7 Jun 2013, Richard W.M. Jones wrote:

> I'll try to look into the items below when I have time, but it'd be great if
> you could just skip over the code here:
>
> http://git.qemu.org/?p=qemu.git;a=blob;f=block/curl.c;h=b8935fd9916363640df142d303b93756c8acf167;hb=HEAD
>
> and tell us if there's anything obviously broken about how it's using the
> API. (Note I didn't write any of it.)

Following such an event-triggered logic is a bit tricky and would require me
to spend some time to fully understand the reasoning behind what's going on.
But I gave it a quick look and found a few things:

I'll start with seconding Kamil's remark about setting options for a handle
that a few lines later gets killed. That seems like an indidication of things
not being entirely right. Also, doing an easy-inteface call in there when you
use the non-blocking event-based API everywhere else seems like perhaps
something to reconsider as well at some point.

Then I noticed two peculiarities which may contribute to what you're
experiencing:

1 - The code uses the multi_socket API but without CURLMOPT_TIMERFUNCTION.
That's highly unusual and I usually strongly advice against it unless you're
perfectly aware of what side-effects it brings ... This can in fact be a
reason for your problem.

2 - its use of curl_multi_socket_all() (which is documented as deprecated
and "do not use") in curl_multi_do() probably mostly hides the problems (1)
causes. Still, it seems to only get called on socket activity, and for example
in the case of a libcurl with a threaded-resolver, there will very certainly
be reasons to call libcurl again without any registered socket activity.

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