On May 6, 8:54 pm, Tristam MacDonald <[email protected]> wrote: > 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. >
Thanks for taking time to explain me that. If this is really a bad idea, I will redesign my app and execute the pyglet part in a subshell, and use network to communicate between the GUI and the renderer. -- 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.
