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 -- http://mail.python.org/mailman/listinfo/python-list
