After being unable to find out what was happening in my app in the previous question, I have tried to reproduce it in my pc using valgrind to find memory / multithread problems. I have seen in many places this:
==769== Possible data race during write of size 4 at 0xACD3ADC by thread #13
==769== Locks held: none
==769== at 0x4C36067: memset (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==769== by 0x4E4570D: pthread_create@@GLIBC_2.2.5 (allocatestack.c:249)
==769== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==769== by 0x509F957: Curl_thread_create (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x50A261B: Curl_resolver_getaddrinfo (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x5066163: Curl_resolv (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x507D74D: Curl_connect (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x508D62F: multi_runsingle (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x508E180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x50857B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x489D63: ConnectionMgr::checkInternetConnection() (ConnectionMgr.cpp:287)
==769== by 0x490E9E: void std::_Mem_fn<void (ConnectionMgr::*)()>::operator()<, void>(ConnectionMgr*) const (in /home/user/app)
==769==
==769== Address 0xACD3ADC is 44 bytes inside a block of size 304 alloc'd
==769== at 0x4C2DFF0: calloc (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==769== by 0x4012E54: _dl_allocate_tls (dl-tls.c:296)
==769== by 0x4E45DA0: pthread_create@@GLIBC_2.2.5 (allocatestack.c:589)
==769== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==769== by 0x509F957: Curl_thread_create (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x50A261B: Curl_resolver_getaddrinfo (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x5066163: Curl_resolv (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x507D74D: Curl_connect (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x508D62F: multi_runsingle (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x508E180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x50857B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==769== by 0x489D63: ConnectionMgr::checkInternetConnection() (ConnectionMgr.cpp:287)
The function I'm running in a separated thread is this one.
void ConnectionMgr::checkInternetConnection()
{
CURL* curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 15);
curl_easy_setopt(curl, CURLOPT_URL,"http://www.google.com");
curl_easy_setopt (curl, CURLOPT_FAILONERROR, 1L);
curl_easy_setopt (curl, CURLOPT_CONNECT_ONLY, 1L);
long responseCode = 404;
curl_easy_perform(curl);
curl_easy_getinfo (curl, CURLINFO_HTTP_CONNECTCODE, &responseCode);
curl_easy_cleanup(curl);
mHasInternet = (responseCode == 200);
}
Thanks a lot.
In common application models, only one thread at a time executes user code, which minimizes the need for thread safety. For this reason, the . NET class libraries are not thread safe by default.
OpenGL commands for a specific context are not thread safe. You should never have more than one thread accessing a single context simultaneously. Contexts that are on different threads can share object resources.
Maybe this question is a bit outdated but I found the answer to it. The problem was that Curl was using signals to notify timeouts on requests and seems not to work fine with multi-threading.
To fix it I used curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1); and after that it worked properly.
Yes!
libcurl is thread-safe under the documented restrictions. Hundreds of applications are using it every day successfully in a threaded way.
Are there any bugs? Sure, and we work hard at fixing all of them that we get reported to the project.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With