Yes.
No. he is from the start just not even asking about only the thread safety at all. He is asking about the thread related limitation on the API. There are much more (thread related) properties on the API then what you can cover with just “threadsafety”.
Still wrong.
Pretty much the only function that is not meant to be threadsafe is the init functions, which cannot be called from multiple thread for reasons completely unrelated to threading as explained above. The only limitations are,
-
It’s pretty much still experimental since we know there’s bug but almost all functions are meant to be threadsafe, if only for the reason that pretty much all of those functions are called by julia itself from multiple threads. This is why it may not be fully documented/marked.
-
Extenal thread is not supported, which is a limitation that’s fairly orthogonal to the general meaning of “threadsafe”.
Again, there are multiple tiers of thread safety. Calling it “not thread safe” means it doesn’t even have a basic level of thread support and julia’s embedding API is well passed that. I take this meaning from your word since you are using it to imply that “Therefore it is recommend as a user of the API to prevent concurrent accesses to Julia API functions”, which is just wrong. Concurrent access of julia API function is no less supported or recommended than using multiple threads in julia itself.
And yes, it’s way too generic. That’s exactly what I’m complaining about because it’s misleading and have led you to the wrong conclusion. You can say jl_init is not thread safe, which at least isn’t wrong even though the reason is largely irrelevant to thread… Or better you should say it doesn’t support external thread, which is the actual limitation.