Hey Mojo team, I’m an AI Native python framework developer and I would love to use your language with my frameworks as plugins for my AI Native tooling.
I haven’t released my package as of yet but they’ll be coming out probably next year.
So what I’m very curious about is I’m building for the freethreaded python binary and my package is a multithreaded concurrency framework with a ton of primitive tooling and a many other features. So my question is does the Mojo programming language interop work with the freethreaded binary and not just that but does it rely on the GIL to ensure that the python thread handle is safely manage?
Or can I spawn n number mojo thread handles if I execute mojo code when it enters mojoland from pythonland. Now when it comes to how I can build that with mojo thats something I will do discovery on.. on my own but at this time thats my biggest question. Do you rely on the GIL or is it freethreaded and I can use it. Because most Interops might use Maturin or Pybind and I think both those systems should work with freethreaded now but I might be wrong.
So I built this package here. I want to use mojo in my compiler. I realize now that there is a ticket active in the github site for mojo. So i’ll wait for that to finish. Looks like 314t is still in progress meanwhile the gil version is supported.
I’m a nogil python developer because the gil just creates a ton of friction and overhead that I’m not interested in. I prefer the .NET style threading. However in the meantime I think I can still build out the compiler in mojo without waiting on the binaries.
I’m hoping to eventually run the strangler fig pattern on my project until its entirely mojo based. That’s my intention. With a small python interface with an interop into the mojo code. That’s my goal.
If it helps at all, we currently handle multi-threading in Mojo by using our Mojo code as a Python extension. We let the Python runtime handle thread creation/destruction. Once each thread runs the Mojo code, we drop the GIL and then can do whatever multi-threaded things we want, at speed.
Inter-thread synchronization is tricky though. Mostly we use a custom mutex built around atomics to handle simple synchronization needs. It can do spin waits and sleep waits, but it’s probably not fast enough for high-throughput needs. If that’s needed, probably you could look into OS APIs for thread parking and wakeups.