Summary: | [CURL] Mutex objects are not required to protect libcurl | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Kwang Yul Seo <skyul> | ||||
Component: | Platform | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | eric, evan, mjs, webkit.review.bot, xan.lopez | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Kwang Yul Seo
2009-12-22 03:19:40 PST
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); Created attachment 45379 [details]
Don't protect libcurl's shared data with mutex
style-queue ran check-webkit-style on attachment 45379 [details] without any errors.
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 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). 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.
Not valid anymore. |