[Python-3000] the future of the GIL (original) (raw)
Giovanni Bajo rasky at develer.com
Sat May 12 03:00:36 CEST 2007
- Previous message: [Python-3000] the future of the GIL
- Next message: [Python-3000] the future of the GIL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 10/05/2007 5.38, Josiah Carlson 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? Cygwin emulates fork() by creating a shared mmap, creating a new child process, copying the contents of the parent process' memory to the child process (after performing the proper allocations), then hacks up the child process' call stack.
Yes that's the theory. If you look at the implementation, it's fullfilled of complexities, corner cases, undocumented glitchs and whatnot.
cygwin's fork() is mature, but I don't think it's easy to extract from cygwin. Moreover, there would be license issues since fork() is GPL. Doing another implementation from scratch is going to be hard.
Giovanni Bajo
- Previous message: [Python-3000] the future of the GIL
- Next message: [Python-3000] the future of the GIL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]