Consider enabling LLVM_ENABLE_THREADS

[vgvassilev]

As per https://github.com/root-project/root/blob/a05d4beded1481a86a65e450826352eb528b03e7/interpreter/CMakeLists.txt#L51 we explicitly disable the llvm threading support. That leaves us on a quite untested code especially with the ORCV2 infrastructure which makes use of asynchronous compilation.

[pcanal]

If we enable ORCV2 asynchronous compilation, it is clear we have to enable threading support in LLVM. So the question is whether we do want to enable ORCV2 asynchronous compilation or not, some things to consider:

• cost to all or most (?) of the interpreter calls (which then would likely takes 2 locks instead of one)
• risk of dead locks; now that the interpreter takes 2 locks, if there is any way that code that takes the LLVM lock calls code directly or indirectly (via user function or even dlopen) take the ROOT locks then they will be dead locks.
• risk of over-subscribing the CPU (i.e. see the many back and forth in the PPP between the way we setup resource sharing between the experiment framework and the implicit multi-threading).
• size of the gain; given than most (but indeed not all) compilation are very small, is it worth the costs?

[dpiparo]

Thanks for this nice proposal. I would like to close the issue. I do not think we will implement this, the second bullet raised by @pcanal is alone probably enough to dismiss the idea, which seemed very good to me at the time, too. @vgvassilev what do you think?

[vgvassilev]

This is really something that could speed up our infrastructure.