search

TheDan64 / inkwell

It's a New Kind of Wrapper for Exposing LLVM (Safely)
https://thedan64.github.io/inkwell/
Apache License 2.0
2.36k stars 227 forks source link

Support for multithreading #28

Open TheDan64 opened 7 years ago

TheDan64 commented 7 years ago

IIRC LLVM supports multithreading. We should support this at some point, if possible. It will likely have it's own set of obstacles. Any Rc types will likely need to be changed to Arc and our existing memory model may or may not need to be further reworked. This is for the far future, so I am marking it as v0.3.0 for now.

novacrazy commented 4 years ago

What's the current plan for this?

TheDan64 commented 4 years ago

There are currently no plans to support multithreaded LLVM. It's still something that we should explore in the future, but single-threaded LLVM is proving to be difficult and time consuming enough as it is to get right

novacrazy commented 4 years ago

Do you have any rough idea as to how you would go about it? I'm working on a language right now and may be able to help if there is time.

TheDan64 commented 4 years ago

No clue. I think the first step is information. I have no idea what LLVM's multithreading mode does concretely. Does Context suddenly become Sync? (Ie is it being locked by a mutex or something?). Furthermore, it's not clear how we would toggle this functionality. LLVM does provide a runtime check to see if multithreaded is enabled, but we would likely need this information at compile time to mark the type as Sync...

JCapucho commented 4 years ago

It seems that it is a compile time gate in llvm https://llvm.org/doxygen/group__LLVMCCoreThreading.html

haochending commented 3 years ago

Is there a work-around at the moment to reuse the jit compiled function from a different thread?

TheDan64 commented 3 years ago

~I don't believe that is thread-safe to do. The functions are raw memory locations, not contained by any sort of locking mechanism~

Edit: It appears EE has its own lock