Le mardi 23 août 2011 à 22:07 +0200, Charles-François Natali a écrit : > 2011/8/23 Antoine Pitrou <solip...@pitrou.net>: > > Well, I would consider the I/O locks the most glaring problem. Right > > now, your program can freeze if you happen to do a fork() while e.g. > > the stderr lock is taken by another thread (which is quite common when > > debugging). > > Indeed. > To solve this, a similar mechanism could be used: after fork(), in the > child process: > - just reset each I/O lock (destroy/re-create the lock) if we can > guarantee that the file object is in a consistent state (i.e. that all > the invariants hold). That's the approach I used in my initial patch.
For I/O locks I think that would work. There could also be a process-wide "fork lock" to serialize locks and other operations, if we want 100% guaranteed consistency of I/O objects across forks. > - call a fileobject method which resets the I/O lock and sets the file > object to a consistent state (in other word, an atfork handler) I fear that the complication with atfork handlers is that you have to manage their lifecycle as well (i.e., when an IO object is destroyed, you have to unregister the handler). Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
