Another face of the discussion is about whether to deprecate the mixing of the threading and processing modules and what to do about the multiprocessing module which is implemented with worker threads.
On Tue, Aug 23, 2011 at 11:29 PM, Antoine Pitrou <solip...@pitrou.net>wrote: > 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/nir%40winpdb.org >
_______________________________________________ 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
