zlibmodule threadsafety changes: RFC

[Titus Brown]

In article <9ljh530253k at enews2.newsguy.com>,
Alex Martelli <aleaxit at yahoo.com> wrote:
>"Titus Brown" <t at chabry.caltech.edu> wrote in message
>news:9lin1v$d57$1 at chabry.caltech.edu...
>    ...
>> Aren't input parameters INCREF'd on the function call into C?  I can't
>
>Nope: if the C code wants to keep hold of them it needs to incref
>them itself (only while the specific Python-called C function itself is
>executing is the object guaranteed not to go away).
>
>> imagine it'd be very cool to have something like:
>>
>> a = "hello there!"
>> fn(a)
>> print a
>> (core dump)
>
>Could happen, if fn decref'd a by more than it addref'd.

Well, yes, and that would be a bug ;).  But I don't have to worry about
the following situation, do I?  (forgive the pseudocode)

c_function(Py_String string)
{
/* do stuff */
BEGIN ALLOW_THREADS
do_something(string)
END_ALLOW_THREADS
/* do stuff */
}

and then:

---
thread1:		thread2:

c_function(s)		
	-->threadswap	del(s)

<core dump, s no longer valid>
---

If thread1 and thread2 were accessing s in different namespaces, then I
would certainly not have to worry about it.  However, if they used s in
the *same* namespace, then only the fact that 's' had been passed into
c_function would be protecting it... Argh, I need to go look into the C
code running this stuff Python!

thanks again,
--titus