Re: curl_multi_perform creates new thread
On Wed, Sep 20, 2023 at 09:11:32PM -0400, Anass Meskini via curl-library wrote: > I compiled curl from the github repository with --with-openssl then I compiled > multi-app.c. > When I run the program in gdb and add a breakpoint for pthread_create I see: curl will use the threaded resolver option by default, so yes, this is expected. You can configure with the --disable-threaded-resolver or --enable-ares option to avoid this. Dan -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl_multi_perform creates new thread
Hello, I compiled curl from the github repository with --with-openssl then I compiled multi-app.c. When I run the program in gdb and add a breakpoint for pthread_create I see: > gdb) bt > #0 __pthread_create_2_1 (newthread=0x55590d50, attr=0x0, > start_routine=0x77f61d20, arg=0x55590fe0) at pthread_create.c:625 > #1 0x77f61da6 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4 > #2 0x77f65224 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4 > #3 0x77f29875 in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4 > #4 0x77f3f2ce in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4 > #5 0x77f5125f in ?? () from /lib/x86_64-linux-gnu/libcurl.so.4 > #6 0x77f520c1 in curl_multi_perform () from > /lib/x86_64-linux-gnu/libcurl.so.4 > #7 0x54ec in main () at main.c:45 > Is this expected? Thanks -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Monitoring of sleeping connections
On Wed, 20 Sep 2023, Matthias Klein via curl-library wrote: What determines the block size libcurl uses to transfer the data? libcurl uses dedicated buffers allocated for downloads and uploads. It even provides options for setting the sizes. It will then always try to receive and send as much as possible so that the TCP stack gets a chance to work optimally. If the stack can't accept more than N bytes when sending, it will say that and curl will then keep the rest of the data in its buffer and pass it on again later at the first opportunity. Is it possible to change the block size to see more frequent changes in the CURLOPT_XFERINFOFUNCTION callback? If you use a smaller upload buffer perhaps, but that then also might hamper your ability to do fast uploads. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Monitoring of sleeping connections
Hi, Context: We use libcurl 7.82.0 with OpenSSL/3.0.10 (Yocto kirkstone) on moving IoT devices to transfer data to the Internet. In some cases we experience sleeping connections, but also slow transfer rates over cellular. (depending on location, provider, etc.). Here we see libcurl transferring larger blocks of data at a time (into the network stack?). It can take some time until the next large block is transferred. This leads to the fact that we don't see any change in the variables dlnow or ulnow in the CURLOPT_XFERINFOFUNCTION callback for a long time. (We continuously get XFERINFOFUNCTION calls with the same values). We monitor the connections by checking for changes in the variables dlnow or ulnow in the CURLOPT_XFERINFOFUNCTION callback. The two unknowns "connection speed" and "block size" make it difficult to implement a monitoring that hits in a timely manner. What determines the block size libcurl uses to transfer the data? Is it possible to change the block size to see more frequent changes in the CURLOPT_XFERINFOFUNCTION callback? Best regards, Matthias -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
