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

Thomas Heller theller@python.net
02 May 2003 18:35:36 +0200

"Tim Peters" <tim_one@email.msn.com> writes:

[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 PyThreadStateSwap(), not in PyThreadStateNew(). So you can create them, but are not allowed to use them? (Should there be a smiley here, or not, I'm not sure)

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.

I'm confused: what is the policy now? And: Has the policy changed, or was it simply not checked before?

Since I don't know the policy, I can only guess if the fatal error is appropriate or not.

If it is, there should be a 'recipe' what to do (even if it is 'use the approach outlined in PEP311').

If it is not, the error should be removed (IMO).

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,

No, not at all.

Thanks,

Thomas