Le lundi 01 février 2010 à 23:20 +0100, "Martin v. Löwis" a écrit : > > I don't know what spawnl is supposed to do, but it really sounds like > the wrong solution.
As far as I understand, I think the idea is to use the same mechanism as under Windows: spawn a new Python interpreter (in a separate process) in order to run the right Python module with the right command-line options. > 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. We must distinguish between locks owned by the thread which survived the fork(), and locks owned by other threads. I guess it's possible if we keep track of the thread id which acquired the lock, and if we give _whatever_after_fork() the thread id of the thread which initiated the fork() in the parent process. Do you think it would be enough to guarantee correctness? _______________________________________________ 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
