On Tue, 13 Sep 2016, Paweł Kopalko wrote:

> You remove the same easy handle twice? And you set an option in between
> which looks really strange?
>
> I found out I remove the handle twice after I posted the example I fixed
> that but there is no change in the behaviour. The idea about the "strange"
> option is from a response from this mailing list:
> https://curl.haxx.se/mail/lib-2016-03/0029.html
> I assumed CURL_RTSPREQ_RECEIVE is required in multi also

multi or easy doesn't change what options you need or needn't set. If you set
it before, you should still set it now.

If you look again at that email you're referring to, Erik set that option in
his easy handle before *adding* the handle to the multi handle, not removing
it.

You can certainly set an option to an easy handle before removing it as well
since the options will be set in the handle until you change it and you can
reuse that handle again very well. As long as you know and understand what
you're doing there's nothing wrong in that per se.

> The problem that I'm facing is that the easy_perform version works great,
> and the multi, just sort of "falls through" to the rtsp_teardown, and the
> write callback gets never called at all. I have about two or three calls
> to multi_perform inside the do {} while() and then it just exits, I can set
> verbose and provide logs if that would help

So what triggers the decision to stop the loop before the transfer is
completed?

> what should in fact be in the do {} while() loop that calls multi_perform ?

You should keep calling multi_perform as long as there's at least one transfer
still alive. Maybe the "Driving with the multi interface" secion in the book
helps:

   http://ec.haxx.se/libcurl-drive-multi.html

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-09-13