Greg Ewing wrote: > Giovanni Bajo wrote: >> using multiple processes cause some >> headaches with frozen distributions (PyInstaller, py2exe, etc.), like those >> usually found on Windows, specifically because Windows does not have fork(). > > Isn't that just a problem with Windows generally? I don't > see what the method of packaging has to do with it. > > Also, I've seen it suggested that there may actually be > a way of doing something equivalent to a fork in Windows, > even though it doesn't have a fork() system call as such. > Does anyone know more about this?
I also wonder about embedded systems and game consoles. I don't know how many embedded microprocessors support fork(), but I know that modern consoles such as PS/3 and Xbox do not, since they have no support for virtual memory at all. Also remember that the PS/3 is supposed to be one of the poster children for multiprocessing -- the whole 'cell processor' thing. You can't write an efficient game on the PS/3 unless it uses multiple processors. Admittedly, not many current console-based games use Python, but that need not always be the case in the future, and a number of PC-based games are using it already. This much I agree: There's no point in talking about supporting multiple processors using threads as long as we're living in a refcounting world. Thought experiment: Suppose you were writing and brand-new dynamic language today, designed to work efficiently on multi-processor systems. Forget all of Python's legacy implementation details such as GILs and refcounts and such. What would it look like, and how well would it perform? (And I don't mean purely functional languages a la Erlang.) For example, in a language that is based on continuations at a very deep level, there need not be any "global interpreter" at all. Each separate flow of execution is merely a pointer to a call frame, the evaluation of which produces a pointer to another call frame (or perhaps the same one). Yes, there would still be some shared state that would have to be managed, but I wouldn't think that the performance penalty of managing that would be horrible. -- Talin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
