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 jcea
Recipients Christophe Simonis, Garen, amaury.forgeotdarc, arekm, asvetlov, doko, eric.araujo, georg.brandl, jcea, jreese, lars.gustaebel, leonov, loewis, nadeem.vawda, nicdumz, nikratio, ockham-razor, pitrou, proyvind, rcoyner, shirish, strombrg, thedjatclubrock, vstinner, ysj.ray
Date 2011-04-08.01:36:16
SpamBayes Score 0.00028420475
Marked as misclassified No
Message-id <>
I think doesn't makes sense for two threads using at the same time the same compress/decompress object. But I could guess ony reason for the locking code is to avoid crashing the interpreter just having two threads racing each other on an inherently mutable object.

Dan, parallel compression simply split the input data and compress each fragment independly. The actual compression object is not shared, each block is compressed with its own self-contained compression context.
Date User Action Args
2011-04-08 01:36:17jceasetrecipients: + jcea, loewis, georg.brandl, doko, amaury.forgeotdarc, arekm, lars.gustaebel, pitrou, vstinner, nadeem.vawda, nicdumz, eric.araujo, Christophe Simonis, rcoyner, proyvind, asvetlov, nikratio, leonov, Garen, ysj.ray, thedjatclubrock, ockham-razor, jreese, strombrg, shirish
2011-04-08 01:36:17jceasetmessageid: <>
2011-04-08 01:36:16jcealinkissue6715 messages
2011-04-08 01:36:16jceacreate