zlibmodule threadsafety changes: RFC

[Alex Martelli]

"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
of
> all input strings before allowing thread swapping to occur.  Is this
likely
> 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


Alex