| 1 |
--- ./mod_wsgi.c.orig 2010-03-09 01:48:50.000000000 -0800 |
| 2 |
+++ ./mod_wsgi.c 2010-07-15 12:31:01.189153878 -0700 |
| 3 |
@@ -5648,6 +5648,26 @@ |
| 4 |
module = PyImport_ImportModule("atexit"); |
| 5 |
Py_XDECREF(module); |
| 6 |
|
| 7 |
+ /* |
| 8 |
+ * In Python 2.6.5 and Python 3.1.2 the shutdown of |
| 9 |
+ * threading was moved back into Py_Finalize() for the main |
| 10 |
+ * Python interpreter. Because we shutting down threading |
| 11 |
+ * ourselves, the second call results in errors being logged |
| 12 |
+ * when Py_Finalize() is called and the shutdown function |
| 13 |
+ * called a second time. The errors don't indicate any real |
| 14 |
+ * problem and the threading module ignores them anyway. |
| 15 |
+ * Whether we are using Python with this changed behaviour |
| 16 |
+ * can only be checked by looking at run time version. |
| 17 |
+ * Rather than try and add a dynamic check, create a fake |
| 18 |
+ * 'dummy_threading' module as the presence of that shuts up |
| 19 |
+ * the messages. It doesn't matter that the rest of the |
| 20 |
+ * shutdown function still runs as everything is already |
| 21 |
+ * stopped so doesn't do anything. |
| 22 |
+ */ |
| 23 |
+ |
| 24 |
+ if (!PyImport_AddModule("dummy_threading")) |
| 25 |
+ PyErr_Clear(); |
| 26 |
+ |
| 27 |
Py_Finalize(); |
| 28 |
|
| 29 |
wsgi_python_initialized = 0; |
