Hi,
I am using clang::ToolInvocation class to compile some code in-memory:
clang::tooling::ToolInvocation ti
(
compilerArgs,
new clang::EmitBCAction(),
new clang::FileManager(clang::FileSystemOptions())
);
//filename is the name of the source file, e.g. "Somefile.cpp"
//sourcecode contains the source of the file
ti.mapVirtualFile( filename, sourcecode );
bool ret = ti.run();
In order to speed up compilation of several sources, I call the above code
concurrently in separate threads, with each thread compiling its own source
code. However, this does not work because clang::CompilerInstance calls
llvm::Sys::RemoveFileOnSignal which in turn calls RegisterHandlers() which
is not re-entrant.
Is there a way of making this parallel compilation work? I do call
llvm::start_multi_threaded() before any of this, hoping that it will make
llvm routines thread-safe, but to no avail. Are there any other classes that
do not set llvm::Sys::RemoveFileOnSignal to true?
Hi,
I am using clang::ToolInvocation class to compile some code in-memory:
clang::tooling::ToolInvocation ti
(
compilerArgs,
new clang::EmitBCAction(),
new clang::FileManager(clang::FileSystemOptions())
);
//filename is the name of the source file, e.g. "Somefile.cpp"
//sourcecode contains the source of the file
ti.mapVirtualFile( filename, sourcecode );
bool ret = ti.run();
In order to speed up compilation of several sources, I call the above code
concurrently in separate threads, with each thread compiling its own source
code. However, this does not work because clang::CompilerInstance calls
llvm::Sys::RemoveFileOnSignal which in turn calls RegisterHandlers() which
is not re-entrant.
Is there a way of making this parallel compilation work? I do call
llvm::start_multi_threaded() before any of this, hoping that it will make
llvm routines thread-safe, but to no avail. Are there any other classes
that
do not set llvm::Sys::RemoveFileOnSignal to true?
All of this is currently not thread-safe. We usually use multiprocessing to
solve the problem. Patches to help making it thread-compatible would be
welcome
The fix in llvm seems straightforward. llvm::sys::RemoveFileOnSignal
releases a mutex too soon. It should hold it till RegisterHandlers()
returns. I will try this out and see if it fixes this issue (and doesn't
break anything else).