Quantcast

[libclang] thread safety issue

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[libclang] thread safety issue

Brian Cain via cfe-dev

Hi,


I've found a potential race condition that can happen in the following code on variable ResourcesPath in tools/libclang/CIndexer.cpp


const std::string &CIndexer::getClangResourcesPath() {
  // Did we already compute the path?
  if (!ResourcesPath.empty())
    return ResourcesPath;

  SmallString<128> LibClangPath;

....
  // Cache our result.
  ResourcesPath = LibClangPath.str();
  return ResourcesPath;
}

Variable ResourcesPath isn't synchronized on so it's possible that another thread might update ResourcesPath at the same time. Is it worth fixing this or is libclang advertised as not thread-safe so it's not worth fixing these types of bugs ?


Thanks,

Ranjeet


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [libclang] thread safety issue

Brian Cain via cfe-dev
AFAIK CIndex is not thread-safe in general, so it's probably not worth fixing. Note that even though the implementation of CIndex might dispatch work to other threads, it will actually wait for them to complete, so it won't race as long as its API is used by a single thread.

I hope this helps,
Alex

On 30 March 2017 at 15:23, Ranjeet Singh via cfe-dev <[hidden email]> wrote:

Hi,


I've found a potential race condition that can happen in the following code on variable ResourcesPath in tools/libclang/CIndexer.cpp


const std::string &CIndexer::getClangResourcesPath() {
  // Did we already compute the path?
  if (!ResourcesPath.empty())
    return ResourcesPath;

  SmallString<128> LibClangPath;

....
  // Cache our result.
  ResourcesPath = LibClangPath.str();
  return ResourcesPath;
}

Variable ResourcesPath isn't synchronized on so it's possible that another thread might update ResourcesPath at the same time. Is it worth fixing this or is libclang advertised as not thread-safe so it's not worth fixing these types of bugs ?


Thanks,

Ranjeet


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [libclang] thread safety issue

Brian Cain via cfe-dev

Hi Alex,


thanks for the quick response.


Yes that answers my question. I'll investigate the thread-safety issues and will decide if it's worth trying to make libclang thread-safe.


Thanks,

Ranjeet


From: Alex L <[hidden email]>
Sent: 30 March 2017 15:34:28
To: Ranjeet Singh
Cc: [hidden email]; nd
Subject: Re: [cfe-dev] [libclang] thread safety issue
 
AFAIK CIndex is not thread-safe in general, so it's probably not worth fixing. Note that even though the implementation of CIndex might dispatch work to other threads, it will actually wait for them to complete, so it won't race as long as its API is used by a single thread.

I hope this helps,
Alex

On 30 March 2017 at 15:23, Ranjeet Singh via cfe-dev <[hidden email]> wrote:

Hi,


I've found a potential race condition that can happen in the following code on variable ResourcesPath in tools/libclang/CIndexer.cpp


const std::string &CIndexer::getClangResourcesPath() {
  // Did we already compute the path?
  if (!ResourcesPath.empty())
    return ResourcesPath;

  SmallString<128> LibClangPath;

....
  // Cache our result.
  ResourcesPath = LibClangPath.str();
  return ResourcesPath;
}

Variable ResourcesPath isn't synchronized on so it's possible that another thread might update ResourcesPath at the same time. Is it worth fixing this or is libclang advertised as not thread-safe so it's not worth fixing these types of bugs ?


Thanks,

Ranjeet


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...