Bug 32864 – [CURL] Mutex objects are not required to protect libcurl

• Component: Platform
• Status: RESOLVED INVALID

[Kwang Yul Seo]

There is a known bug in libcurl's threaded resolver in Win32:

crash using libcurl 7.19 multi interface
http://curl.haxx.se/mail/lib-2009-03/0092.html

In the past, Kevin Watters suggested a solution to fix the crash by protecting libcurl's shared data with mutex.

curl DNS lookup occurs on multiple threads but storage is not threadsafe
https://bugs.webkit.org/show_bug.cgi?id=28920

I'm afraid that this is not the correct way to solve the problem. As mentioned in the libcurl's mailing list, this bug is caused by the internal bug in libcurl's threaded DNS resolver.

According to the libcurl's manual:

"Since you can use this share from multiple threads, and libcurl has no internal thread synchronization, you must provide mutex callbacks if you're using this multi-threaded. "

Because ResourceHandleManager is single-threaded with multi interface, we don't need thread synchronization at all.

The right way to fix this problem is to use the synchronous resolver or c-ares resolver in libcurl build as mentioned in the mailing list. The current ResourceHandleManager code causes unnecessary locking overhead in other platforms.

[Kwang Yul Seo]

With multi interface, the DNS data is automatically shared. So the following line is also unnecessary.

curl_share_setopt(m_curlShareHandle, CURLSHOPT_SHARE, CURL_LOCK_DATA_DNS);

[Kwang Yul Seo]

Created attachment 45379 [details]
Don't protect libcurl's shared data with mutex

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45379 [details] without any errors.

[Kwang Yul Seo]

Another solution for this problem is keep the current workaround with platform-specific guards so that other platforms are not affected.

We can get rid of mutex callbacks once the problem is fixed in libcurl itself.

I see the work in progress:

http://curl.haxx.se/mail/lib-2009-09/0316.html

http://sourceforge.net/tracker/index.php?func=detail&aid=2884791&group_id=976&atid=100976

[Eric Seidel (no email)]

What will removing this code do?

Will it expose a crasher?  Will it make things faster?  Will it remove dead code?

Your changelog is nice, but I'm still not clear on the purpose of this change.  You explained more What than Why (both are useful).

[Eric Seidel (no email)]

Comment on attachment 45379 [details]
Don't protect libcurl's shared data with mutex

No response in over 2 weeks.  r-.  Please re-flag when you've answered my question.

[Kwang Yul Seo]

Not valid anymore.