== BPython ==

Another experiment to support threading properly. By default the Python Interpreter releases its lock every 100 instructions so that other threads get a chance to run Python code and API calls. But that is not enough to prevent race conditions causing artifacts (and maybe crashes) during threaded rendering, since all threads will access the same pynodes data.

So I'm disabling this automatic releasing of the lock (the GIL) by the interpreter, which seems to be a better option for how Blender uses Python.

1 files changed, 7 insertions, 1 deletions

diff --git a/source/blender/python/BPY_interface.c b/source/blender/python/BPY_interface.c
index 8adaddf14c5..2336c343f68 100644
--- a/source/blender/python/BPY_interface.c
+++ b/source/blender/python/BPY_interface.c
@@ -232,6 +232,13 @@ void BPY_start_python( int argc, char **argv )
 	/* Initialize thread support (also acquires lock) */
 	PyEval_InitThreads();
 
+	/* Don't allow the Python Interpreter to release the GIL on
+	 * its own, to guarantee PyNodes work properly. For Blender this
+	 * is currently the best default behavior.
+	 * The following code in C is equivalent in Python to:
+	 * "import sys; sys.setcheckinterval(sys.maxint)" */
+	_Py_CheckInterval = PyInt_GetMax();
+
 	//Overrides __import__
 	init_ourImport(  );
 	init_ourReload(  );
@@ -242,7 +249,6 @@ void BPY_start_python( int argc, char **argv )
 	//Look for a python installation
 	init_syspath( first_time ); /* not first_time: some msgs are suppressed */
 
-	//PyEval_ReleaseLock();
 	py_tstate = PyGILState_GetThisThreadState();
 	PyEval_ReleaseThread(py_tstate);