[issue1164] tp_print slots don't release the GIL

New submission from Armin Rigo: The tp_print slots, used by 'print' statements, don't release the GIL while writing into the C-level file. This is not only a missing opportunity, but can cause unexpected deadlocks, as shown in the attached file. -- components: Interpreter Core files: de

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: I quickly handled the GIL for lists and ints in their tp_print functions and your example still deadlocked. Don't have time to dig deeper right now, but what more are you suggesting be done? -- nosy: +brett.cannon __ Track

[issue1164] tp_print slots don't release the GIL

Armin Rigo added the comment: We need to start from PyFile_WriteString() and PyFile_WriteObject() and PyObject_Print(), which are what the PRINT_* opcodes use, and make sure there is no single fprintf() or fputs() that occurs with the GIL held. It is not enough to fix a few places that could cle

[issue1164] tp_print slots don't release the GIL

Guido van Rossum added the comment: Plese do submit a patch. FWIW I think it's solved in Py3k, the tp_print slot is dead (as is any use of the C stdio library). -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __

[issue1164] tp_print slots don't release the GIL

Changes by Brett Cannon: -- versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: Since I already did this once I just did a more thorough job; patch is attached. PyObject_WriteString() just calls PyFile_WriteObject() which ends up using PyObject_Print(), so it is was simple to handle those cases. I then released the GIL for strings, lists, an

[issue1164] tp_print slots don't release the GIL

Changes by Brett Cannon: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1164] tp_print slots don't release the GIL

Guido van Rossum added the comment: Looks Good, except I think it's a bad idea to release/acquire the GIL for each character when writing the repr() of a string. Given that the string is immutable and its refcount kept alive by the caller I don't see a reason why you can't just reference the obj

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: Good point. I changed it on my machine and it cut that whole section down to a single release/acquire. I will go ahead and do this for the other types and then upload another patch to be reviewed when it's ready. __ Tracker <[EMAI

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: OK, every PyTypeObject in Objects and Modules has its tp_print release the GIL. Once someone OKs the patch I will apply it. __ Tracker <[EMAIL PROTECTED]> __ GIL_r

[issue1164] tp_print slots don't release the GIL

Guido van Rossum added the comment: looks good to me :) -- assignee: -> brett.cannon __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mai

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: Applied in r58176. And I am glad this is not an issue in Py3K. =) -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __