Message 78318 - Python tracker

➜

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	vstinner
Recipients	ebfe, pitrou, vstinner
Date	2008-12-26.23:34:42
SpamBayes Score	1.1925161e-05
Marked as misclassified	No
Message-id	<1230334483.87.0.968265075301.issue4738@psf.upfronthosting.co.za>
In-reply-to

Content
New comments about the last patch: - GIL is not released for adler() or crc32() whereas these functions may be slow for long strings: just add Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS before / after adler(...) and crc32(...) - (As ENTER_HASHLIB, issue #4751) I think that Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS are useless in ENTER_ZLIB - You might add explicit self to ENTER/LEAVE_ZLIB because the macros are now dependent of self (and not the whole module) => ENTER_ZLIB(self) and LEAVE_ZLIB(self) Are deflateCopy() and inflateCopy() slow enough to release the GIL?

New comments about the last patch:
 - GIL is not released for adler() or crc32() whereas these functions 
may be slow for long strings: just add Py_BEGIN_ALLOW_THREADS / 
Py_END_ALLOW_THREADS before / after adler(...) and crc32(...)
 - (As ENTER_HASHLIB, issue #4751) I think that 
Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS are useless in 
ENTER_ZLIB
 - You might add explicit self to ENTER/LEAVE_ZLIB because the macros 
are now dependent of self (and not the whole module) => 
ENTER_ZLIB(self) and LEAVE_ZLIB(self)

Are deflateCopy() and inflateCopy() slow enough to release the GIL?

History
Date	User	Action	Args
2008-12-26 23:34:43	vstinner	set	recipients: + vstinner, pitrou, ebfe
2008-12-26 23:34:43	vstinner	set	messageid: <1230334483.87.0.968265075301.issue4738@psf.upfronthosting.co.za>
2008-12-26 23:34:43	vstinner	link	issue4738 messages
2008-12-26 23:34:43	vstinner	create