| Nicolas Lehuen 2006-05-20, 7:11 am |
| OK, it seems that my last hypothesis was the good one : mod_python is
doing things with thread states that are frowned upon by debug build.
The tests are only performed in the debug build, so that's why we had
no problem with the release build.
The tests are found in pystate.c, in function PyThreadState_Swap (line
297 in the current trunk revision) :
=09/* It should not be possible for more than one thread state
=09 to be used for a thread. Check this the best we can in debug
=09 builds.
=09*/
#if defined(Py_DEBUG) && defined(WITH_THREAD)
=09if (newts) {
=09=09PyThreadState *check =3D PyGILState_GetThisThreadState();
=09=09if (check && check->interp =3D=3D newts->interp && check !=3D newts)
=09=09=09Py_FatalError("Invalid thread state for this thread");
=09}
#endif
So it seems mod_python is trying to share the same thread state
between multiple threads, which "should not be possible". If someone
has an idea, please help me, because I'm not really up to date about
thread state management, so I'll have to read a fair bit of
documentation before understanding what's happening there.
Regards,
Nicolas
2006/5/20, Nicolas Lehuen <nicolas@lehuen.com>:
> I've forgot to mention the platform : as usual for me, it's Windows XP SP=
2.
>
> Regards,
> Nicolas
>
> 2006/5/20, Nicolas Lehuen <nicolas@lehuen.com>:
d of[vbcol=seagreen]
was[vbcol=seagreen]
eter[vbcol=seagreen]
that[vbcol=seagreen]
r that[vbcol=seagreen]
>
|