This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients Louis Brandy, Piotr Wysocki, cooperlees, drothera, gregory.p.smith, lukasz.langa, phantez, pixelbeat, vstinner
Date 2017-05-24.17:40:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1495647604.73.0.0951182374687.issue30395@psf.upfronthosting.co.za>
In-reply-to
Content
Another alternative *might* be to check if the lock is locked (non-blocking acquire?) and release it if so. Under the normal assumption that we are the only thread running immediately post-fork().

I'm not sure that can be guaranteed reliable given that other C code could've used pthread_atfork to register an "after" fork handler that spawns threads.  But that should be rare, and nothing here can really fix the underlying "programmer has mixed fork and threads" issue. Only ameliorate it.

But i'm not sure this post fork memory leak is really a problem other than potentially showing up in memory sanatizer runs involving forked children.  The scenario where it would be an actual leak is if a process does serial fork() calls with the parent(s) dying rather than forking new children from a common parent.  That would grow the leak as each child would have an additional lock allocated (a few bytes).  I don't _believe_ that kind of process pattern is common (but people do everything).
History
Date User Action Args
2017-05-24 17:40:04gregory.p.smithsetrecipients: + gregory.p.smith, vstinner, pixelbeat, lukasz.langa, cooperlees, Louis Brandy, drothera, phantez, Piotr Wysocki
2017-05-24 17:40:04gregory.p.smithsetmessageid: <1495647604.73.0.0951182374687.issue30395@psf.upfronthosting.co.za>
2017-05-24 17:40:04gregory.p.smithlinkissue30395 messages
2017-05-24 17:40:04gregory.p.smithcreate