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 nadeem.vawda
Recipients Christophe Simonis, Garen, Nam.Nguyen, amaury.forgeotdarc, arekm, asvetlov, barry, doko, eric.araujo, georg.brandl, jcea, jeremybanks, lars.gustaebel, leonov, loewis, nadeem.vawda, nicdumz, nikratio, ockham-razor, pitrou, proyvind, rcoyner, shirish, strombrg, thedjatclubrock, tshepang, vstinner, ysj.ray
Date 2011-10-11.10:03:31
SpamBayes Score 1.1565329e-07
Marked as misclassified No
Message-id <1318327413.31.0.63298674751.issue6715@psf.upfronthosting.co.za>
In-reply-to
Content
Awesome stuff! I'll post an updated patch during the course of the day.

Martin: I've been having problems with Rietveld lately, so I'm posting
my replies to your comments here instead.

>> Modules/_lzmamodule.c:115: return _PyBytes_Resize(buf, size + BIGCHUNK);
> This has quadratic performance.

Correct. I copied the algorithm from _io.FileIO, under the assumption
that there was a reason for not using a simpler O(n log n) doubling
strategy. Do you know of any reason for this? Or is it safe to ignore it?

>> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS
> It seems that the Windows version at least is not thread-safe. If so, you
> would need an LZMA lock when releasing the GIL.

Does the class need to be thread-safe, though? ISTM that there isn't any
sensible use case for having two threads feeding data through the same
compressor concurrently.

(If we *do* want thread-safety, then it doesn't matter whether the
underlying lib is internally thread-safe or not. We would still need to
guard against the possibility of the _lzmamodule.c code in one thread
modifying the lzma_stream's input or output pointer while lzma_code is
operating on the stream's data in another thread.)
History
Date User Action Args
2011-10-11 10:03:33nadeem.vawdasetrecipients: + nadeem.vawda, loewis, barry, georg.brandl, doko, jcea, amaury.forgeotdarc, arekm, lars.gustaebel, pitrou, vstinner, nicdumz, eric.araujo, Christophe Simonis, rcoyner, proyvind, asvetlov, nikratio, leonov, Garen, ysj.ray, thedjatclubrock, ockham-razor, strombrg, shirish, tshepang, jeremybanks, Nam.Nguyen
2011-10-11 10:03:33nadeem.vawdasetmessageid: <1318327413.31.0.63298674751.issue6715@psf.upfronthosting.co.za>
2011-10-11 10:03:32nadeem.vawdalinkissue6715 messages
2011-10-11 10:03:32nadeem.vawdacreate