Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl_multi_timeout and the multi_socket API
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Henrik Holst via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 3 Apr 2021 19:02:18 +0200
Den lör 3 apr. 2021 kl 18:41 skrev Fulup Ar Foll <fulup.arfoll_at_iot.bzh>:
> Henrik,
>
> Curl timeout and mainloop timer as in my sample with libuv, epool, ... are
> completely independent. Curl handle its own timer to remind you when you're
> supose to do some action. But as soon transfert start you only handle
> communication go through the main event loop.
>
> In order to use epool, you only need to map what I did for livuv, nothing
> more nothing less. You only need to write the 'epoll' version of
> https://github.com/fulup-bzh/libcurl-mainloop/blob/main/glue-libuv.c and
> you should only call one curl_multi_timeout()
>
>
As I wrote earlier, usually when you call curl_multi_add_handle(), the
Timer Function CB is called once by curl with timeout set to 0. Then when
you call curl_multi_socket_action() with CURL_SOCKET_TIMEOUT the Timer
Function CB is usually called once more but this time with a timeout set to
1. If you do not call curl_multi_socket_action() again with
CURL_SOCKET_TIMEOUT after 1ms then curl stalls indefinitely since there
will be no read or write events triggering the event handler to return
events, in fact you won't even get a call to your Socket Function CB before
you handle that first 1ms timeout.
Now I might have misread what you wrote, but some external timer is still
needed so the question at hand is if having such a timer is more or less
complexity/overhead than simply calling curl_multi_timeout().
/HH
Fulup
>
> On 03/04/2021 16:08, Henrik Holst wrote:
>
>
>
> Den lör 3 apr. 2021 kl 10:40 skrev Fulup Ar Foll <fulup.arfoll_at_iot.bzh>:
>
>> Henrik,
>>
>> I wrote an example using either sytemd or libuv main loop, it might
>> eventually help you https://github.com/fulup-bzh/libcurl-mainloop
>>
> Thanks, I can see that you use the timer functionatilty in libuv and
> systemd to avoid the problems that I'm talking about. The main question
> then is if a call to curl_multi_timeout() before each call to epoll_wait()
> / poll() / select() is more or less overhead than using timers.
>
> /HH
>
>>
>> Fulup
>>
>> On 02/04/2021 23:08, Henrik Holst via curl-library wrote:
>>
>>
>>
>> Den fre 2 apr. 2021 kl 23:05 skrev Daniel Stenberg <daniel_at_haxx.se>:
>>
>>> On Fri, 2 Apr 2021, Henrik Holst via curl-library wrote:
>>>
>>> > for (;;)
>>> > int ret = poll (fds, nfds, timeout);
>>> >
>>> > if (ret == 0) {/* timeout */
>>> > curl_multi_socket_action (curlm, CURL_SOCKET_TIMEOUT, 0,
>>> > &running_handles);
>>> > } else if (ret != -1) { /* events */
>>> > if (fds[0].revents != 0)
>>> > curl_multi_socket_action (curlm, fds[0].fd, fds[0].revents,
>>> > &running_handles);
>>> > else if (fds[1]).revents != 0)
>>> > ...
>>> > }
>>> > }
>>>
>>> This is a typical example of an event loop that should rather use
>>> curl_multi_perform() or perhaps even just curl_multi_poll(). And yes,
>>> for such
>>> an event loop you want curl_multi_timeout (at least unless you use
>>> curl_multi_poll).
>>>
>>> If you use poll() then the multi socket API is probably the wrong
>>> choice. The
>>> multi socket API is for event-based handling.
>>>
>> Okey, but the very same thing happens with epoll, or are we only defining
>> event-based handling as say libevent, libev and libuv?
>> /HH
>>
>> -------------------------------------------------------------------
>> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>>
>>
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-03
Date: Sat, 3 Apr 2021 19:02:18 +0200
Den lör 3 apr. 2021 kl 18:41 skrev Fulup Ar Foll <fulup.arfoll_at_iot.bzh>:
> Henrik,
>
> Curl timeout and mainloop timer as in my sample with libuv, epool, ... are
> completely independent. Curl handle its own timer to remind you when you're
> supose to do some action. But as soon transfert start you only handle
> communication go through the main event loop.
>
> In order to use epool, you only need to map what I did for livuv, nothing
> more nothing less. You only need to write the 'epoll' version of
> https://github.com/fulup-bzh/libcurl-mainloop/blob/main/glue-libuv.c and
> you should only call one curl_multi_timeout()
>
>
As I wrote earlier, usually when you call curl_multi_add_handle(), the
Timer Function CB is called once by curl with timeout set to 0. Then when
you call curl_multi_socket_action() with CURL_SOCKET_TIMEOUT the Timer
Function CB is usually called once more but this time with a timeout set to
1. If you do not call curl_multi_socket_action() again with
CURL_SOCKET_TIMEOUT after 1ms then curl stalls indefinitely since there
will be no read or write events triggering the event handler to return
events, in fact you won't even get a call to your Socket Function CB before
you handle that first 1ms timeout.
Now I might have misread what you wrote, but some external timer is still
needed so the question at hand is if having such a timer is more or less
complexity/overhead than simply calling curl_multi_timeout().
/HH
Fulup
>
> On 03/04/2021 16:08, Henrik Holst wrote:
>
>
>
> Den lör 3 apr. 2021 kl 10:40 skrev Fulup Ar Foll <fulup.arfoll_at_iot.bzh>:
>
>> Henrik,
>>
>> I wrote an example using either sytemd or libuv main loop, it might
>> eventually help you https://github.com/fulup-bzh/libcurl-mainloop
>>
> Thanks, I can see that you use the timer functionatilty in libuv and
> systemd to avoid the problems that I'm talking about. The main question
> then is if a call to curl_multi_timeout() before each call to epoll_wait()
> / poll() / select() is more or less overhead than using timers.
>
> /HH
>
>>
>> Fulup
>>
>> On 02/04/2021 23:08, Henrik Holst via curl-library wrote:
>>
>>
>>
>> Den fre 2 apr. 2021 kl 23:05 skrev Daniel Stenberg <daniel_at_haxx.se>:
>>
>>> On Fri, 2 Apr 2021, Henrik Holst via curl-library wrote:
>>>
>>> > for (;;)
>>> > int ret = poll (fds, nfds, timeout);
>>> >
>>> > if (ret == 0) {/* timeout */
>>> > curl_multi_socket_action (curlm, CURL_SOCKET_TIMEOUT, 0,
>>> > &running_handles);
>>> > } else if (ret != -1) { /* events */
>>> > if (fds[0].revents != 0)
>>> > curl_multi_socket_action (curlm, fds[0].fd, fds[0].revents,
>>> > &running_handles);
>>> > else if (fds[1]).revents != 0)
>>> > ...
>>> > }
>>> > }
>>>
>>> This is a typical example of an event loop that should rather use
>>> curl_multi_perform() or perhaps even just curl_multi_poll(). And yes,
>>> for such
>>> an event loop you want curl_multi_timeout (at least unless you use
>>> curl_multi_poll).
>>>
>>> If you use poll() then the multi socket API is probably the wrong
>>> choice. The
>>> multi socket API is for event-based handling.
>>>
>> Okey, but the very same thing happens with epoll, or are we only defining
>> event-based handling as say libevent, libev and libuv?
>> /HH
>>
>> -------------------------------------------------------------------
>> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>>
>>
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-03