zlibmodule threadsafety changes: RFC

Alex Martelli aleaxit at yahoo.com
Fri Aug 17 09:21:39 CEST 2001

"Titus Brown" <t at chabry.caltech.edu> wrote in message
news:9lifo8$cdv$1 at chabry.caltech.edu...
> 2) the input strings to the de/compress functions can be modified
>    outside of the zlibmodule while the zlibmodule functions are
>    working on them.

Python strings are immutable.  Strings CANNOT be modified, ever.
Just make sure you addref the string object when you start using
it and decref it when you're done with it, so it doesn't get freed
from under your nose, of course.

> First off, my fix for the second problem involves making an internal copy
> all input strings before allowing thread swapping to occur.  Is this
> to cause unacceptable memory usage?  If so, should I add a fair bit more

Yes, but it shouldn't be necessary thanks to strings' immutability.

> Second of all, my fix to the first problem involves a *global* zlib lock.
> Now, if I put a lock in de/compression objects themselves, then
> on a multiprocessor machine, multiple de/compression objects could run
> on multiple processors.  However, this adds some thorny (to me) issues

No opinion, since I don't have SMP boxes to play with right now.

> http://chabry.caltech.edu/~t/transfer/zlibmodule.c

I get a 404 on this:
Not Found
The requested URL /~t/transfer/zlibmodule.c was not found on this server.


Apache/1.3.17 Server at sea-urchin.caltech.edu Port 80


More information about the Python-list mailing list