curl-library
Re: How do you know when the read/write callbacks are done and transfer is complete?
Date: Thu, 21 Jan 2010 23:48:27 +0530
Its the multi scenario that interests me. You have a few easy handles, and
the easy handles keep arriving and leaving (how to manage that?) and they
may hang around till you decide you want to do another request on that URL,
or set up another URL on the easy handle.
Can you do this without multithreading? I mean, i havent seen any good
examples of how this can be done with curl. curl hides a lot of info, which
is not a bad thing, but i guess i am just wondering how well the multi
interface is designed to handle this kind of thing. Maybe if the user was
allowed to associate a "user data" in the callback and then in the callback
you get the user cookie in which you stuff the easy handle and then do what
you say below on that easy handle that might make code organisation more
nice and far less messy.
Also, can you use thread pools with curl?
Date: Thu, 21 Jan 2010 09:06:26 -0600
From: Jeff Pohlmeyer <yetanothergeek_at_gmail.com>
To: libcurl development <curl-library_at_cool.haxx.se>
Subject: Re: How do you know when the read/write callbacks are done
and transfer is complete?
Message-ID:
<a275e6d01001210706n5251669ere5b13562770fff14_at_mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 21, 2010 at 8:47 AM, vick wrote:
> You have the option of associating read/write callbacks
> with an easy handle.
> How do you know when the transfer is complete?
> Is the callback called again with some special code?
> how do you figure that out?
if you're using the "single" api, curl_easy_perform won't return
until the transfer is complete.
if you're using the "multi" api, things get a little more complicated -
you need call curl_multi_info_read() in a loop and check each handle
for CURLMsg->msg == CURLMSG_DONE.
- Jeff
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-01-21