Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

["Martin v. Löwis"]

Ross Ridge schrieb:
> Martin v. Löwis wrote:
>> How would you propose to fix file_repr to prevent such
>> a race condition?
> 
> The race condition you describe is different from the one Joe Seigh
> described.  It's caused because without GIL access to the file object
> is no longer thread safe, not because reference counting isn't thread
> safe.

Joe's claim (quoting him) was: "Atomic increment and decrement
instructions are not by themselves sufficient to make reference
counting safe."

Rephrasing this in Python terms is "if the GIL is dropped and
incref/decref are made atomic, the reference counting is not
automatically thread-safe". This is what my example demonstrates:
Drop the GIL, and assume an atomic inc/dec, and it won't be
thread-safe.

It's not that the file object becomes thread-unsafe. Instead,
access to the f_name property won't work anymore (as would
access to any other PyObject* field).

You still didn't say what you would suggest to make it thread-safe
again; most likely, you proposal would be to add locking. If I
understand Joe's approach correctly, he has a solution that does
not involve locking (although I don't understand how it works).

Regards,
Martin