curl_multi_timeout and the multi_socket API

Dear libcurl devs, in the docs the curl_multi_timeout() function has this note: "An application that uses the multi_socket API SHOULD NOT use this function, but SHOULD instead use curl_multi_setopt and its CURLMOPT_TIMERFUNCTION option for proper and desired behavior." However as I see there a

Re: curl_multi_timeout and the multi_socket API

Den fre 2 apr. 2021 kl 23:05 skrev Daniel Stenberg : > 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_SOC

Re: curl_multi_timeout and the multi_socket API

Den fre 2 apr. 2021 kl 23:12 skrev Daniel Stenberg : > On Fri, 2 Apr 2021, Henrik Holst wrote: > > >> 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

Re: curl_multi_timeout and the multi_socket API

Den lör 3 apr. 2021 kl 00:01 skrev Daniel Stenberg : > On Fri, 2 Apr 2021, Henrik Holst wrote: > > >> What "very same thing" is it that happens? > > > > For epoll, the "very same thing" is that if a non-curl socket is added > to > > the epoll efd then epoll_wait() would just like poll() enter a si

Re: curl_multi_timeout and the multi_socket API

md 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: >

Re: curl_multi_timeout and the multi_socket API

ainloop >> > 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

Re: curl_multi_timeout and the multi_socket API

Den lör 3 apr. 2021 kl 22:56 skrev Fulup Ar Foll : > Henrik, > > I posted this sample on github because I lost too many hours searching for > curl logic in the documentation. You have to respect curl_timeout, > nevertheless if your mainloop works well, it should be call only once per > download. I

Re: curl_multi_timeout and the multi_socket API

Den sön 4 apr. 2021 kl 00:06 skrev Fulup Ar Foll : > I'm not sure to understand your logic. If you have to call > curl_multi_timeout() at each iteration of your mainloop your logic should > be wrong. > I never said that I had to, just that one could (in order to avoid having a timer, aka if the la

Re: curl_multi_timeout and the multi_socket API

Den sön 4 apr. 2021 kl 12:28 skrev Daniel Stenberg : > On Sat, 3 Apr 2021, Henrik Holst wrote: > > (Let me just add some meat to this and explain this described behavior.) > > > As I wrote earlier, usually when you call curl_multi_add_handle(), the > Timer > > Function CB is called once by curl wi

Re: curl_multi_timeout and the multi_socket API

Den sön 4 apr. 2021 kl 12:28 skrev Daniel Stenberg : > On Sat, 3 Apr 2021, Henrik Holst wrote: > > (Let me just add some meat to this and explain this described behavior.) > > > As I wrote earlier, usually when you call curl_multi_add_handle(), the > Timer > > Function CB is called once by curl wi

Re: curl_multi_timeout and the multi_socket API

Den mån 5 apr. 2021 kl 18:39 skrev Fulup Ar Foll : > Henrik, > > I confirm what Daniel said. If you take 100% of CPU your logic is > obviously wrong. > > If you run with a main loop, it is up to your your code to select which > socket is ready for reading. From your mainloop callback your should c

Re: curl_multi_timeout and the multi_socket API

Den mån 5 apr. 2021 kl 17:33 skrev Daniel Stenberg : > On Mon, 5 Apr 2021, Henrik Holst wrote: > > > On a side note (and perhaps I should have written this in a separate > mail) I > > did notice that the timer function callback returns far too low values > for > > long polling http servers if the

Re: curl_multi_timeout and the multi_socket API

Den mån 5 apr. 2021 kl 20:06 skrev Henrik Holst < henrik.ho...@millistream.com>: > > > Den mån 5 apr. 2021 kl 18:39 skrev Fulup Ar Foll : > >> Henrik, >> >> I confirm what Daniel said. If you take 100% of CPU your logic is >> obviously wrong. >> >> If you run with a main loop, it is up to your you

Re: curl_multi_timeout and the multi_socket API

and of course now that I reread the docs on CURLMOPT_TIMERFUNCTION I do see the "non-repeating timer" text Sorry for wasting everybody's time here, I'll learn to read before posting again... /HH Den mån 5 apr. 2021 kl 20:51 skrev Henrik Holst < henrik.ho...@millistream.com>: > > > Den mån 5

Re: curl_multi_timeout and the multi_socket API

Den mån 5 apr. 2021 kl 22:43 skrev Daniel Stenberg : > On Mon, 5 Apr 2021, Henrik Holst wrote: > > > And this particular run with 1ms did not lead to 100% cpu, it was when > curl > > gave me 0ms as timeout as the last timeout which lead me to call > > curl_multi_socket_action() every 0ms, which tu

Re: CURLOPT_WRITEDATA user pointer not being passed in callback

Den mån 5 apr. 2021 kl 22:35 skrev J Curl via curl-library < curl-library@cool.haxx.se>: > I am trying to write a http client to send a HTTPs PUT request and save > the response in memory. To try this I have combined the anyauthput.c > and getinmemory.c

Re: curl 7.66.0 to 7.76.0 yield make error: `sa_family_t' undeclared

Hi, AFAIK a sa_family_t should be equivalent to a unsigned short (or perhaps rather uint16_t) /HH Den mån 19 apr. 2021 kl 17:46 skrev Kevin R. Bulgrien via curl-library < curl-library@cool.haxx.se>: > Having successfully built recent versions of curl on a very old UNIX > (SCO OpenServer 5.0.7

Re: [hint] : using curl to write a program to send and receive some file to server.

Hi David, there are many source code examples on the curl site and one in particular that exactly covers what you are after is: https://curl.se/libcurl/c/anyauthput.html it's just that it also proves some code to handle the "any auth" which you probably don't need but if so then you can simply i

Re: POST Request with non-null-terminated string

HI, libcurl handles the data you point to with CURLOPT_POSTFIELDS as raw byte data, or rather "ibcurl will not convert or encode it for you in any way" as the doc says. Could be that your webserver requires a different Content-Type header to receive it correctly. If you use http then I would fi

Re: Feature request: new callback to report http chunks boundaries

It depends on which JSON parser that you use, e.g YAJL have a setting yajl_allow_multiple_values which allows you to constantly feed data into the parser and it will still handle each JSON object as separate objects. And I bet that other parsers have similar functionality. To get out of the error

Re: curl websockets

Would it not be better to use the normal URI used for Websockets which are "ws(s)://" instead of the http(s) or am I missing something? /HH Den ons 23 juni 2021 kl 17:28 skrev Daniel Stenberg via curl-library < curl-library@cool.haxx.se>: > On Tue, 22 Jun 2021, Weston Schmidt via curl-library wr

Re: Recv failure error under censorship conditions

As your own research shows they are most definitely filtering based on user-agent. Probably done in order to filter out access from various mobile phone apps. There could of course be other types of filters as well but your example clearly demonstrates the presence of a user-agent filter for web b

Re: Recv failure error under censorship conditions

just fyi this is how the same request looks from here in Europe (added -v to show more verbose): henrik@ubuntu:~/utveckling/other/mdf_client$ curl -Iv google.com * Trying 172.217.20.46:80... * TCP_NODELAY set * Connected to google.com (172.217.20.46) port 80 (#0) > HEAD / HTTP/1.1 > Host: google

Re: Killed!

Sounds like you are getting OOM-killed, check dmesg or /var/log/messages if there are ny info about OOM kicking in /HH Den lör 24 juli 2021 kl 09:22 skrev XSLT2.0 via curl-library < curl-library@cool.haxx.se>: > Hello, > > Have you heard of any instance when the use of libcurl would "kill" > -di