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 nirai
Recipients bobbyi, gregory.p.smith, neologix, nirai, pitrou, vstinner
Date 2011-05-12.20:01:49
SpamBayes Score 0.0031417215
Marked as misclassified No
Message-id <>

There seem to be two alternatives for atfork handlers:
1) acquire locks during prepare phase and unlock them in parent and child after fork.
2) reset library to some consistent state in child after fork.

Option (2) makes sense but is probably not always applicable.
Option (1) depends on being able to acquire locks in locking order, but how can we determine correct locking order across libraries?

Initializing locks in child after fork without acquiring them before the fork may result in corrupted program state and so is probably not a good idea.

On a positive note, if I understand correctly, Python signal handler functions are actually run in the regular interpreter loop (as pending calls) after the signal has been handled and so os.fork() atfork handlers will not be restricted to async-signal-safe operations (since a Python fork is never done in a signal handler).
"It is therefore undefined for the fork handlers to execute functions that are not async-signal-safe when fork() is called from a signal handler."

Opinion by Butenhof who was involved in the standardization effort of POSIX threads: how can we establish correct (cross library) locking order during prepare stage?

Date User Action Args
2011-05-12 20:01:51niraisetrecipients: + nirai, gregory.p.smith, pitrou, vstinner, bobbyi, neologix
2011-05-12 20:01:51niraisetmessageid: <>
2011-05-12 20:01:50nirailinkissue6721 messages
2011-05-12 20:01:50niraicreate