On Wed, Jul 1, 2009 at 02:22, Mohun Biswas<m_biswas_at_mailinator.com> wrote:
> Hardeep Singh wrote:
>>
>> On Mon, Jun 29, 2009 at 10:46, Daniel Stenberg<daniel_at_haxx.se> 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
Received on 2009-07-01