Hello all, The zlib interface does not indicate when you've hit the end of a compressed stream.
The underlying zlib functionality provides for this. With python's zlib, you have to read past the compressed data and into the uncompressed, which gets stored in Decompress.unused_data. As a result, if you've got a network protocol which mixes compressed and non-compressed output, you may find a compressed block ending with no uncompressed data following until you send another command -- which a synchronous (non-pipelined) client will not send, because it is waiting for the [compressed] data from the previous command to be finished. As a result, you get a protocol deadlock. A simple way to fix this would be to add a finished attribute to the Decompress object. However, perhaps this would be a good time to discuss how this library works; it is somewhat awkward and perhaps there are other changes which would make it cleaner. What does the python community think? -- Crypto ergo sum. http://www.subspacefield.org/~travis/ Do unto other faiths as you would have them do unto yours. If you are a spammer, please email j...@subspacefield.org to get blacklisted. -- http://mail.python.org/mailman/listinfo/python-list