Allow multiple Clang instances per thread.

[reitermarkus]

Depends on KyleMayes/clang-sys#145.

Previously, you could only create one Clang across all threads. This is a problem when trying to use Clang in tests which run in parallel. This change allows creating multiple Clang instances per thread while still only loading libclang once per thread.

[reitermarkus]

@KyleMayes, I updated this to not use KyleMayes/clang-sys#145.

[reitermarkus]

Note that I'm not actually sure if this true.

Depending on whether libclang is thread-safe or not, we either need to allow

1 Clang instance per thread where Clang: !Send + !Sync

or we need to allow

1 Clang instance per process where Clang: Send.

[reitermarkus]

@KyleMayes, could you have another look here?

[reitermarkus]

@nagisa, maybe you could also take a look here since this seems relevant for #26.

[nagisa]

FWIW #26 was so long ago, I pretty much forgotten all about what it was about. That said, it isn't clear to me some of the premises here are accurate:

This change allows creating multiple Clang instances per thread while still only loading libclang once per thread.

Dynamically loading a library is still a process-wide reference-counted affair (this is just how dynamic loaders work). This cannot be changed unless some non-portable dl* APIs are used. It just that constructing a structure containing function pointers to all the symbols is gonna happen per-thread which seems like a wasted effort, given that the code could just have a static CLANG: Once<...>.

[KyleMayes]

I used to be somewhat knowledgeable about this kind of thing (loading libraries and stuff) but I haven't put much thought into this library for years (except when I need to do essential maintenance to keep it functioning so that I can fulfill my duty to the Rust ecosystem 🫡). I'm on vacation for the next week or so, if y'all haven't hashed it out by then I'll take another look at this.

…

On Mon, Nov 14, 2022, 22:12 Simonas Kazlauskas ***@***.***> wrote: FWIW #26 <#26> was so long ago, I pretty much forgotten all about what it was about. That said, it isn't clear to me some of the premises here are correct. This change allows creating multiple Clang instances per thread while still only loading libclang once per thread. Dynamically loading a library is still a process-wide reference-counted affair (this is just how dynamic loaders work). This cannot be changed unless some non-portable dl* APIs are used. It just that constructing a structure containing function pointers to all the symbols is gonna happen per-thread which seems like a wasted effort, given that the code could just have a static CLANG: Once<...>. — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHYCKEUEU44MSKQA5NKFLLWIKTNRANCNFSM6AAAAAAQOY7ZZY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[reitermarkus]

It just that constructing a structure containing function pointers to all the symbols is gonna happen per-thread which seems like a wasted effort, given that the code could just have a static CLANG: Once<...>.

That's exactly the problem: Clang is not Send, so you cannot have a static containing it.

Currently, we can only have a single instance per-process, which cannot be shared, so we need one of the two options described in #46 (comment).

[RobbeDGreef]

Are there any updates on this? I am encountering the same problem.