On Mon, Feb 1, 2010 at 5:20 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > Antoine Pitrou wrote: >> Jesse Noller <jnoller <at> gmail.com> writes: >>> I don't see the need for the change from fork as of yet (for >>> multiprocessing) and I am leery to change the internal implementation >>> and semantics right now, or anytime soon. I'd be interested in seeing >>> the patch, but if the concern is that global threading objects could >>> be left in the state that they're in at the time of the fork(), I >>> think people know that or we can easily document this fact. >> >> If Pascal provides a patch I think it would really be good to consider it. >> Not being able to mix threads and multiprocessing is a potentially annoying >> wart. > > I don't know what spawnl is supposed to do, but it really sounds like > the wrong solution. > > Instead, we should aim to make Python fork-safe. If the primary concern > is that locks get inherited, we should change the Python locks so that > they get auto-released on fork (unless otherwise specified on lock > creation). This may sound like an uphill battle, but if there was a > smart and easy solution to the problem, POSIX would be providing it. > > Regards, > Martin
Posix threads expose the _atfork function _______________________________________________ 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
