Author sbt
Recipients Giovanni.Bajo, bobbyi, gregory.p.smith, jcea, lesha, neologix, nirai, pitrou, sbt, sdaoden, vinay.sajip, vstinner
Date 2012-06-02.18:06:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1338660381.39.0.957335889921.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content
Lesha, the problems about "magical" __del__ methods you are worried about actually have nothing to do with threading and locks.  Even in a single threaded program using fork, exactly the same issues of potential corruption would be present because the object might be finalized at the same in multiple processes.

The idea that protecting the object with a thread lock will help you is seriously misguided UNLESS you also make sure you acquire them all before the fork -- and then you need to worry about the order in which you acquire all these locks.  There are much easier and more direct ways to deal with the issue than wrapping all objects with locks and trying to acquire them all before forking.

You could of course use multiprocessing.Lock() if you want a lock shared between processes.  But even then, depending on what the __del__ method does, it is likely that you will not want the object to be finalized in both processes.

However, the suggestion that locked-before-fork-locks should by default raise an error is reasonable enough.
History
Date User Action Args
2012-06-02 18:06:21sbtsetrecipients: + sbt, gregory.p.smith, vinay.sajip, jcea, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, lesha
2012-06-02 18:06:21sbtsetmessageid: <1338660381.39.0.957335889921.issue6721@psf.upfronthosting.co.za>
2012-06-02 18:06:20sbtlinkissue6721 messages
2012-06-02 18:06:19sbtcreate