Charles-François Natali <neolo...@free.fr> added the comment: >> - how do you find the correct order to acquire locks in the parent process? > > One option is to use the import graph to determine call order of atfork > handlers. > If a current std library does not fit into this scheme we can possibly fix it > when writing its handlers. >
Sorry, I fail to see how the "import graph" is related to the correct lock acquisition order. Some locks are created dynamically, for example. That's why I asked for a specific API: when do you register a handler? When are they called? When are they reset? >> - what do you do with locks that can be held for arbitrarily long (e.g. I/O >> locks)? > > It is likely that such a lock does not need acquiring at the parent, and > re-initializing the library in the child handler will do. The whole point of atfork is to avoid breaking invariants and introduce invalid state in the child process. If there is one thing we want to avoid, it's precisely reading/writting corrupted data from/to files, so eluding the I/O problem seems foolish to me. > A "critical section" lock that protects in-memory data should not be held > for long. Not necessarily. See for example I/O locks and logging module, which hold locks until I/O completion. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
