curl-library
Re[6]: Working with curl connections as with sockets.
Date: Sun, 4 May 2008 22:41:50 +0400
Hello Nathan,
Sunday, May 4, 2008, 6:21:48 PM, you wrote:
>> typedef enum {
>> CURLDIR_IN, /* can safely call curl_easy_recv() */
>> CURLDIR_OUT /* can safely call curl_easy_send() */
>> } CURLdirection;
>>
>> /* returns true if the handle can be read from or written to;
>> returns false in case of timeout */
>> bool curl_easy_poll(CURL *curl, CURLdirection d, double timeout_in_sec);
NEM> The other libcurl functions where a timeout is used take a long with time
NEM> in milliseconds.
Ok, I do not insist at all - this was an example of a possible
implementation. Let it be long. :)
NEM> What if I want to wait on more than one socket?,
You can collect the sockets with CURLIFO_LASTSOCKET and wait on them
using any suitable system function. Or, if performance is not a big
issue, you can poll the connections in a cycle like this:
long timeout = global_timeout / number_of_handles;
for(i = 0; i < number_of_handles; i++)
{
if(curl_easy_poll(handle[i], CURLDIR_IN, timeout))
do_something_with_data(handle[i]);
}
My proposal is to add an easy-to-use, cross-platform, single-handle
interface for waiting on the socket and checking its status. This is
enough for *all* applications that use single connection; it will also
be enough for applications that have one connection per thread.
If your application requires something beyond this functionality, then
you should go down to sockets.
NEM> or use a g_io_channel to tell me when I can write?
I am not familiar with g_io_channel, but I assume it accepts sockets -
so nothing can prevent you from obtaining one.
-- Best regards, Tetetest mailto:tetetest_at_rambler.ruReceived on 2008-05-04