Gregory P. Smith added the comment: pthread_atfork() cannot be used to implement this. Another non-python thread started by a C extension module or the C application that is embedding Python within it is always free to call fork() on its own with zero knowledge that Python even exists at all. It's guaranteed that fork will be called while the Python GIL is held in this situation which would cause any pre-fork thing registered by Python to deadlock.
At best, this can be implemented manually as we do with some of the before and after fork stuff today but it must come with the caveat warning that it cannot guarantee that these things are actually called before and after fork() other than direct os.fork() calls from Python code or extremely Python aware C extension modules that may call fork() (very rare, most C & C++ libraries an extension module may be using assume that they've got the run of the house). ie: this problem is unsolvable unless you control 100% of the code being used by your entire user application. On Mon, Nov 19, 2012 at 3:59 PM, Gregory P. Smith <rep...@bugs.python.org>wrote: > > Gregory P. Smith added the comment: > > I would not allow exceptions to propagate. No caller is expecting them. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue16500> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
