Need pthread_atfork-like functionality in CPython #51172
Description
| BPO | 6923 |
|---|---|
| Nosy | @Yhg1s, @gpshead, @jcea |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/Yhg1s'
closed_at = <Date 2013-08-21.18:44:31.642>
created_at = <Date 2009-09-16.20:03:12.259>
labels = ['interpreter-core', 'type-feature']
title = 'Need pthread_atfork-like functionality in CPython'
updated_at = <Date 2013-08-21.18:44:31.641>
user = 'https://github.com/Yhg1s'bugs.python.org fields:
activity = <Date 2013-08-21.18:44:31.641>
actor = 'neologix'
assignee = 'twouters'
closed = True
closed_date = <Date 2013-08-21.18:44:31.642>
closer = 'neologix'
components = ['Interpreter Core']
creation = <Date 2009-09-16.20:03:12.259>
creator = 'twouters'
dependencies = []
files = []
hgrepos = []
issue_num = 6923
keywords = []
message_count = 2.0
messages = ['92715', '92765']
nosy_count = 3.0
nosy_names = ['twouters', 'gregory.p.smith', 'jcea']
pr_nums = []
priority = 'low'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '16500'
type = 'enhancement'
url = 'https://bugs.python.org/issue6923'
versions = []
Activity
Yhg1s commentedon Sep 16, 2009
In order to properly handle multiple threads and fork()-calls from C code
(rather than os.fork()), Python should provide pthread_atfork()-like
functionality: a function to call before a fork, to acquire any locks
that need to be acquired, and a pair of functions to call after the fork,
in the parent and the child, to release or re-allocate locks. The
acquisitions should be re-entrant and should not require an existing
threadstate. Also see <http://bugs.python.org/issue1590864\>.
gpshead commentedon Sep 17, 2009
For reference, this is related to http://bugs.python.org/issue6721 but
deals with the C API side of things for an atfork mechanism to be used by
extension modules.