Re: questions about multi API
Date: Fri, 3 Jul 2009 16:57:52 +0530
I am getting the following error while executing my test prog.
getaddrinfo(3) failed for tikona2.techmahindra.com:80
* Couldn't resolve host 'tikona2.techmahindra.com'
* Closing connection #0
* couldn't resolve host name
Response = 6
Please help and it's very urgent.
Thanks in advance
On Mon, Jun 29, 2009 at 9:56 PM, Mohun Biswas <m_biswas_at_mailinator.com>wrote:
> I have a few questions about the multi API, even after reading the
> - The doc states that curl_multi_perform "will only execute as little as
> possible and then return back control to your program". Taken literally this
> would mean it transfers one byte with each "ready" socket, but I'm guessing
> it really means that one buffer's worth is exchanged, and return
> CURLM_CALL_MULTI_PERFORM if more could be done?
> - 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? In other words I think I
> shouldn't use the above loop if my program has other high-priority things to
> - Is there a technique for "serializing" the multi API? By which I mean
> something like a flag to change the "as little as possible" philosophy to
> "as much as possible", which would make it behave much more synchronously
> like the easy API. I'm thinking this could be useful for debugging. For
> instance, I've completely rewritten my own program to use multi and,
> predictably, there are bugs. It's not clear to what degree these are caused
> by asynchrony itself (race conditions, etc) or simply mistakes introduced in
> the rewrite. Seems to me that serializing could be a great
> divide-and-conquer approach.
Received on 2009-07-03