+//---------------------------------------------------------------------------
+
+//static bool _wxPyInEvent = false;
+static unsigned int _wxPyNestCount = 0;
+
+HELPEREXPORT bool wxPyRestoreThread() {
+// #ifdef WXP_WITH_THREAD
+// //if (wxPyEventThreadState != PyThreadState_Get()) {
+// if (! _wxPyInEvent) {
+// PyEval_RestoreThread(wxPyEventThreadState);
+// _wxPyInEvent = true;
+// return TRUE;
+// } else
+// #endif
+// return FALSE;
+
+ // NOTE: The Python API docs state that if a thread already has the
+ // interpreter lock and calls PyEval_RestoreThread again a deadlock
+ // occurs, so I put in the above code as a guard condition since there are
+ // many possibilites for nested events and callbacks in wxPython.
+ //
+ // Unfortunately, it seems like somebody was lying (or I'm not
+ // understanding...) because each of the nested calls to this function
+ // MUST call PyEval_RestoreThread or Python pukes with a thread error (at
+ // least on Win32.)
+ //
+ // until I know better, this is how I am doing it instead:
+#ifdef WXP_WITH_THREAD
+ PyEval_RestoreThread(wxPyEventThreadState);
+ _wxPyNestCount += 1;
+ if (_wxPyNestCount == 1)
+ return TRUE;
+ else
+#endif
+ return FALSE;
+}
+
+
+HELPEREXPORT void wxPySaveThread(bool doSave) {
+#ifdef WXP_WITH_THREAD
+ if (doSave) {
+ PyEval_SaveThread();
+ //_wxPyInEvent = false;
+ }
+ _wxPyNestCount -= 1;
+#endif
+}
+
+//---------------------------------------------------------------------------
+