[Python-Dev] New thread death in test_bsddb3 (original) (raw)

Tim Peters tim_one@email.msn.com
Wed, 30 Apr 2003 23:50:32 -0400

[Thomas Heller]

... So is the policy now that it is no longer allowed to create another thread state, while in previous versions there wasn't any choice, because there existed no way to get the existing one?

You can still create all the thread states you like; the new check is in PyThreadState_Swap(), not in PyThreadState_New().

There was always a choice, but previously Python provided no help in keeping track of whether a thread already had a thread state associated with it. That didn't stop careful apps from providing their own mechanisms to do so.

About policy, yes, it appears to be so now, else Mark wouldn't be raising a fatal error . I view it as having always been the policy (from a good-faith reading of the previous code), just a policy that was too expensive for Python to enforce. There are many policies like that, such as not passing goofy arguments to macros, and not letting references leak. Python doesn't currently enforce them because it's currently too expensive to enforce them. Over time that can change.

IMO a fatal error is very harsh, especially there's no problem to continue execution - excactly what happens in a release build.

There may or may not be a problem with continued execution -- if you've associated more than one living thread state with a thread, your app may very well be fatally confused in a way that's very difficult to diagnose without this error.

Clearly, I like having fatal errors for dubious things in debug builds. Debug builds are supposed to help you debug. If the fatal error here drives you insane, and you don't want to repair the app code, you're welcome to change

#if defined(Py_DEBUG)

to

#if 0

in your debug build.

Not that I am misunderstood: I very much appreciate the work Mark has done, and look forward to use it to it's fullest extent.

In what way is this error a genuine burden to you? The only time I've seen it trigger is in the Berkeley database wrapper, where it pointed out a fine opportunity to simplify some obscure hand-rolled callback tomfoolery -- and pointed out that the thread in question did in fact already have a thread state. Whether that was correct in all cases is something I don't know -- and don't have to worry about anymore, since the new code reuses the thread state the thread already had. The lack of errors in a debug run now assures me that's in good shape now.