Martin v. Löwis <mar...@v.loewis.de> added the comment: >>> 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?
As a matter of principle, Python code must not be able to crash the interpreter or corrupt memory. There are known bugs in this area, but if it's known in advance that an issue exists, we should avoid it. > ISTM that there isn't any > sensible use case for having two threads feeding data through the same > compressor concurrently. Right. So having a per-compressor mutex lock would be entirely reasonable. I could also accept a per-module lock. I could even accept the GIL, and if no other code is forth-coming, I would prefer to keep holding the GIL during comprssion over risking crashes. > (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.) I haven't reviewed the module in this respect. If you say that it wouldn't be thread-safe even if LZMA was compiled as thread-safe, then this definitely must be fixed. To elaborate on the policy: giving bogus data in cases of race conditions is ok; crashing the interpreter or corrupting memory is not. If bogus data is given, it would be useful if the bogosity can be specified (e.g. when multiple threads read from the same POSIX file concurrently, they also get bogus data, but in a manner where each input byte is given to exactly one thread). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6715> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com