Hello, 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 Regards, Vamshi. On Mon, Jun 29, 2009 at 9:56 PM, Mohun Biswas <[email protected]>wrote: > I have a few questions about the multi API, even after reading the > documentation: > > - 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 > do? > > - 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. > > Thanks, > MB > >
