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 cagney
Recipients Birne94, Connor.Wolf, Giovanni.Bajo, Winterflower, bobbyi, cagney, dan.oreilly, davin, emptysquare, forest_atq, gregory.p.smith, ionelmc, jcea, lesha, neologix, nirai, nirs, ochedru, pitrou, sbt, sdaoden, tshepang, vinay.sajip, vstinner
Date 2019-04-04.17:11:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1554397869.1.0.168746766878.issue6721@roundup.psfhosted.org>
In-reply-to
Content
> acquiring locks before fork in the thread doing the forking and releasing them afterwards is always the safe thing to do.

It's also an easy way to cause a deadlock:

- register_at_fork() et.al. will cause per-logger locks to be acquired before the global lock (this isn't immediately obvious from the code)

If a thread were to grab its logging lock before the global lock then it would deadlock.  I'm guessing this isn't allowed - however I didn't see any comments to this effect?

Can I suggest documenting this, and also merging the two callbacks so that the ordering of these two acquires is made explicit.

- the per-logger locks are acquired in a random order

If a thread were to acquire two per-logger locks in a different order then things would deadlock.
History
Date User Action Args
2019-04-04 17:11:09cagneysetrecipients: + cagney, gregory.p.smith, vinay.sajip, jcea, nirs, pitrou, vstinner, nirai, forest_atq, ionelmc, bobbyi, neologix, Giovanni.Bajo, sdaoden, tshepang, sbt, lesha, emptysquare, dan.oreilly, davin, Connor.Wolf, Winterflower, Birne94, ochedru
2019-04-04 17:11:09cagneysetmessageid: <1554397869.1.0.168746766878.issue6721@roundup.psfhosted.org>
2019-04-04 17:11:09cagneylinkissue6721 messages
2019-04-04 17:11:08cagneycreate