IronPython interoperates with a whole host of C and C++ code. I'm not sure why this would matter?
The initial implementation may need to assume single-threaded C interface support and take a global lock but it wouldn't be a stretch to have these things declare they are multithread aware and relax that restriction.
Forgive me but most of these objections seem like post-hoc rationalizations. The first step is deciding to support a GIL-less multithreaded mode. After that, solve the problems one step at a time.
It is amazing how many times accomplishing "magic" boils down to:
1. Decide we're going to solve this problem.
2. Iterate toward the solution in manageable steps.
Jython uses the JNI and IronPython does it through C++/CLI, neither of them support the CPython extension interface, meaning the C modules aren't compatible. Because of this, Jython and IronPython inherit the interface properties of their respective VMs and they can remain thread safe without the GIL.
The initial implementation may need to assume single-threaded C interface support and take a global lock but it wouldn't be a stretch to have these things declare they are multithread aware and relax that restriction.
Forgive me but most of these objections seem like post-hoc rationalizations. The first step is deciding to support a GIL-less multithreaded mode. After that, solve the problems one step at a time.
It is amazing how many times accomplishing "magic" boils down to:
1. Decide we're going to solve this problem. 2. Iterate toward the solution in manageable steps.
#1 is by far the most difficult aspect :)