paulkirth added a comment.

In D67253#1670681 <https://reviews.llvm.org/D67253#1670681>, @lebedev.ri wrote:

> Re concurrency - you had standalone `LLVMContext` for each thread, right?


I believe there was, but this is just whatever happens when libtooling creates 
and executes a compiler invocation. It seems to me that there is some global 
state that ends up being shared between threads. I wasn’t able to fully trace 
the issue, but it at least partly involves the processing of backend options. I 
believe there is more, that needs to be addressed but this is probably a good 
place for me to start. Thanks for the suggestion.

> 
> 
> In D67253#1670667 <https://reviews.llvm.org/D67253#1670667>, @paulkirth wrote:
> 
>> In D67253#1670569 <https://reviews.llvm.org/D67253#1670569>, @lebedev.ri 
>> wrote:
>>
>> > Layering feels weird here.
>> >  Can this be implemented as/limited to just a
>> >  `run-clang-misexpect.py` wrapper over clang itself?
>> >  That would be best IMHO.
>>
>>
>> I discussed the concurrency issue with some folks who work on libTooling, 
>> notably Sam McCall & Dmitri Gribenko. This was the approach they suggested I 
>> follow. LibTooling also provides some nice mechanisms for curating compiler 
>> options, which is possible, but less than ideal to reimplement in a python 
>> script. There are probably more benefits that escape me at the moment, but 
>> that was the first one I thought of.
>>
>> Out of curiosity, if the concurrency issue was fixed in the compiler and the 
>> python script was removed/deprecated, would you still feel the same way?
> 
> 
> I was actually talking/thinking about the opposite direction, only having the 
> .py wrapper, no standalone tool;
>  so the opposite solution (no .py, only the tool) is tangential/has different 
> direction.

Right, I was asking if you still see this as an issue if the python script 
wasn’t necessary. I take from this comment that it would not make you feel 
differently.

I think ultimately keeping the implementation in c++ makes the most sense and 
can evolve with the rest of libtooling.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67253/new/

https://reviews.llvm.org/D67253



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to