On Wed, Jul 1, 2009 at 02:22, Mohun Biswas<[email protected]> wrote: > Hardeep Singh wrote: >> >> On Mon, Jun 29, 2009 at 10:46, Daniel Stenberg<[email protected]> wrote: >>> >>> On Mon, 29 Jun 2009, Mohun Biswas wrote: >>>> >>>> - The docs also say "It is designed to never block". A common idiom >>>> mentioned in the docs and used often in the examples is to call >>>> curl_multi_perform in a loop: >>>> >>>> while (CURLM_CALL_MULTI_PERFORM == curl_multi_perform(...)); >>>> >>>> if I understand correctly, this will will treat all easy handles >>>> "fairly" >>>> without blocking, but will effectively "block" any non-curl-related >>>> activity >>>> until all curl transfers are done. Is that right? >>> >>> Sure, but that while() is in the app not in libcurl. >> >> For the reason that this loop is in the app, a separate thread can be >> launched to run this loop and doesn't block the rest of the app... >> Does this eliminate the need for serializing? > > Not sure if this point is addressed to me or Daniel but in any case the > libcurl docs say about threading "The first basic rule is that you must > never share a libcurl handle (be it easy or multi or whatever) between > multiple threads". So I don't think this is an option. > > And as Daniel points out the loop is not required, it's just quite common. I > guess the point is it's the right thing to do iff all your important work is > being done by the libcurl multi API. > > MB > >
Mohun, As far as I understood we should not share a handle means there shouldn't be simultaneous calls in multiple threads for the same handle. But then I am not a libcurl expert. Others in the community can verify or correct this understanding. In our project we allocate and add a handle using curl_multi_add_handle in a separate thread. The curl_multi_perform is called in a separate thread. It is called asynchronously when select() sees some action on sockets. Changes to CurlMultihandle are under a lock. So there is no sharing of libcurl handle and no app blocking. Hope it helps. -hardy
