This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fdirosa
Recipients Rhamphoryncus, fdirosa, grahamd, nnorwitz, timbishop, vslavik
Date 2008-07-21.15:39:19
SpamBayes Score 0.0005878833
Marked as misclassified No
Message-id <1216654764.26.0.314159538552.issue1758146@psf.upfronthosting.co.za>
In-reply-to
Content
"Also, that Py_DEBUG check effectively says that if you use simplified 
GIL API for a particular thread against the first interpreter, you are 
prohibited from creating additional thread states for that thread."

I found that you cannot create additional thread states against the 
first interpreter and swap between them w/o this assertion occurring.  
I didn't use the GIL functions at all and had this issue in debug.  
PyInitialize initializes the GIL and hijacks the main interpreter.  We 
always call PyInitialize so does that mean we can only use the GIL 
functions with the main interpreter and nothing else when 
locking/unlocking the global lock as you seem to infer?  Does that mean 
there is a backward compatibility issue here with those who used the 
main interpreter only and created thread states from it to handle multi-
threading, like I did (thru the use of PyEval_Acquire/Release & 
PyThreadState_Swap)?
History
Date User Action Args
2008-07-21 15:39:24fdirosasetspambayes_score: 0.000587883 -> 0.0005878833
recipients: + fdirosa, nnorwitz, Rhamphoryncus, timbishop, vslavik, grahamd
2008-07-21 15:39:24fdirosasetspambayes_score: 0.000587883 -> 0.000587883
messageid: <1216654764.26.0.314159538552.issue1758146@psf.upfronthosting.co.za>
2008-07-21 15:39:23fdirosalinkissue1758146 messages
2008-07-21 15:39:19fdirosacreate