On Thu, May 6, 2010 at 2:25 PM, luper <[email protected]> wrote: > The following code fails silently (the child process segfaults): > > -*-*-*-*-*-*-*-*-*-*-*-*-*-*- > from multiprocessing import Process > import pyglet > > def run(): > window = pyglet.window.Window() > pyglet.app.run() > > import pyglet.gl > p = Process(target=run) > p.start() > p.join() > -*-*-*-*-*-*-*-*-*-*-*-*-*-*- > > Commenting out the "import pyglet.gl" line fixes the problem. Setting > "pyglet.options["shadow_window"] = False" fixes it too, so this is > related to the shadow window created by pyglet when importing > pyglet.gl [1] > > I don't understand why this problem occurs, maybe some issue related > to hardware resources when copying the shadow context created by > pyglet from the parent to the child process ? The fork() manpage says > nothing about this, and apart from random people telling me this is a > "bad idea" I wasn't able to find any information.
I don't know the exact cause of your crash, but I do know that what you doing here is a very, very bad idea. First off, you can't fork on Windows - the fork syscall doesn't exist. You can emulate fork in other ways, but these methods are generally neither simple nor reliable for GUI applications. The likely source of your crash, however, is that fork'ing a process which is currently holding heavy-weight OS resources (such as an OpenGL context, a thread, or a window), is almost guaranteed to fail, no matter what system. Disabling the shadow window prevents pyglet from allocating an OpenGL context, but I am not sure that it guarantees not to allocate any graphical resources in this case - and I wouldn't suggest relying on this behaviour unless it is clearly documented. The only safe way to fork in a application that deals with heavy-weight resources is to fork *before* those resources are allocated. In this case, that means forking before pyglet is imported, if you must use fork. I would suggest that you redesign you application not to use fork - there are generally better methods ;) > The fact that pyglet fails silently made this problem difficult to > track down, maybe an explicit error message could be added by patching > os.fork() with something like this? I don't think we want to go messing around with the low-level modules like this. After all, this isn't a limitation imposed by pyglet, it is a general limitation of fork in modern OS environments. -- Tristam MacDonald http://swiftcoder.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
