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_perform creates new thread
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 21 Sep 2023 17:04:45 -0700
On Thu, Sep 21, 2023 at 12:08:33PM -0400, Anass Meskini via curl-library wrote:
> Thanks Dan for the clarification.
> I think it might be worth mentioning in the doc that this function might create
> a thread.
It is called the "threaded resolver" after all, and that name is found in 8
different documentation files in the source tree, including in
libcurl-thread(3) which is the go-to location for information about threading
in libcurl. Where else would you like to see it? curl_multi_perform(3) seems
like a poor place for it, because *absolutely everything* happens in a call to
curl_multi_perform and we can't document everything there.
> Would setting CURLOPT_RESOLVE result in curl_multi_perform never creating a new
> thread?
I'm pretty sure that the name resolve cache is checked before the system
resolver thread is created, so this should work.
> Also when I run multi-app.c in helgrind, I see:
>
> ==339231== ---Thread-Announcement------------------------------------------
> ==339231==
> ==339231== Thread #1 is the program's root thread
> ==339231==
> ==339231== ----------------------------------------------------------------
> ==339231==
> ==339231== Thread #1: pthread_mutex_destroy with invalid argument
> ==339231== at 0x483FC96: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/
> vgpreload_helgrind-amd64-linux.so)
> ==339231== by 0x572D16F: ??? (in /usr/lib/x86_64-linux-gnu/
> libp11-kit.so.0.3.0)
> ==339231== by 0x4011F6A: _dl_fini (dl-fini.c:138)
> ==339231== by 0x49468A6: __run_exit_handlers (exit.c:108)
> ==339231== by 0x4946A5F: exit (exit.c:139)
> ==339231== by 0x4924089: (below main) (libc-start.c:342)
> ==339231==
> ==339231== ----------------------------------------------------------------
> ==339231==
> ==339231== Thread #1: pthread_mutex_destroy with invalid argument
> ==339231== at 0x483FC96: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/
> vgpreload_helgrind-amd64-linux.so)
> ==339231== by 0x4011F6A: _dl_fini (dl-fini.c:138)
> ==339231== by 0x49468A6: __run_exit_handlers (exit.c:108)
> ==339231== by 0x4946A5F: exit (exit.c:139)
> ==339231== by 0x4924089: (below main) (libc-start.c:342)
>
>
> Are these false positives?
Not that I'm aware. Note that libcurl uses pthread mutexes aside from
threading, so these a not (necessarily) related to the threaded resolver. Other
libraries like OpenSSL, GnuTLS and libssh also uses mutexes, so this might not
ever be an issue in libcurl.
Dan
Date: Thu, 21 Sep 2023 17:04:45 -0700
On Thu, Sep 21, 2023 at 12:08:33PM -0400, Anass Meskini via curl-library wrote:
> Thanks Dan for the clarification.
> I think it might be worth mentioning in the doc that this function might create
> a thread.
It is called the "threaded resolver" after all, and that name is found in 8
different documentation files in the source tree, including in
libcurl-thread(3) which is the go-to location for information about threading
in libcurl. Where else would you like to see it? curl_multi_perform(3) seems
like a poor place for it, because *absolutely everything* happens in a call to
curl_multi_perform and we can't document everything there.
> Would setting CURLOPT_RESOLVE result in curl_multi_perform never creating a new
> thread?
I'm pretty sure that the name resolve cache is checked before the system
resolver thread is created, so this should work.
> Also when I run multi-app.c in helgrind, I see:
>
> ==339231== ---Thread-Announcement------------------------------------------
> ==339231==
> ==339231== Thread #1 is the program's root thread
> ==339231==
> ==339231== ----------------------------------------------------------------
> ==339231==
> ==339231== Thread #1: pthread_mutex_destroy with invalid argument
> ==339231== at 0x483FC96: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/
> vgpreload_helgrind-amd64-linux.so)
> ==339231== by 0x572D16F: ??? (in /usr/lib/x86_64-linux-gnu/
> libp11-kit.so.0.3.0)
> ==339231== by 0x4011F6A: _dl_fini (dl-fini.c:138)
> ==339231== by 0x49468A6: __run_exit_handlers (exit.c:108)
> ==339231== by 0x4946A5F: exit (exit.c:139)
> ==339231== by 0x4924089: (below main) (libc-start.c:342)
> ==339231==
> ==339231== ----------------------------------------------------------------
> ==339231==
> ==339231== Thread #1: pthread_mutex_destroy with invalid argument
> ==339231== at 0x483FC96: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/
> vgpreload_helgrind-amd64-linux.so)
> ==339231== by 0x4011F6A: _dl_fini (dl-fini.c:138)
> ==339231== by 0x49468A6: __run_exit_handlers (exit.c:108)
> ==339231== by 0x4946A5F: exit (exit.c:139)
> ==339231== by 0x4924089: (below main) (libc-start.c:342)
>
>
> Are these false positives?
Not that I'm aware. Note that libcurl uses pthread mutexes aside from
threading, so these a not (necessarily) related to the threaded resolver. Other
libraries like OpenSSL, GnuTLS and libssh also uses mutexes, so this might not
ever be an issue in libcurl.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-09-22