[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] fork() and PyGame?



On Wednesday, Oct 1, 2003, at 15:17 America/New_York, Michael wrote:

you'll find fork() is a little extreme for what you want. when you fork your program you create an entirely new process, with its own independent copy of all the program data. the only way the two processes can talk to each other is some form of IPC (socket, sharedmem, etc).
hopefully that's clear enough. it sounds like what you want are separate threads, not forked processes. threads are a little more lightweight, and share all global variables and resources. in this case one thread could read the pygame event queue and another thread do some drawing.
still, you may find the threading more trouble than it's worth. it can lead to many tricky situations that you hadn't even imagined.
I reworked my code to use events to keep ongoing tasks being processed without blocking. Works okay. I was mostly interested in why fork() didn't work. I was going to try threads but decided that unblocking my code would be easier.
I think most GUI frameworks don't like when you fork. On OS X for example, you're not supposed to fork after a certain point of initialization (after you've starting hitting the CoreFoundation framework, which is useful even for non-GUI applications). Windows doesn't have a fork. In general, just don't use fork.

since your app has to update the screen once per frame, it makes a lot of sense to just process all the events during that time too. my guess is your ui design has multiple little "main loops" where each ui widget gets control of the app when it has input focus?
Not yet. Right now it uses a single loop to process input. I want to redo my UI layer eventually but not until after it's all working. It's easier to correct mistakes than predict them. :)
If the whole app is designed to be event driven, you don't need to fork, ever. Applications written using the Twisted framework are a very good example of this. That model works particularly good for Python because Python is bad at threading due to the GIL. Concurrency is not built into the language, so it's hard to do. On multiprocessor machines you're highly likely to see better Python performance with the multiple-processes-with-network-communication model, and that model also scales very easily to clusters or multiple machines. The threading model is just not really a good way to do things in Python, you really only ought to use them if the frameworks you're using demand it (on BeOS maybe?) or if you're writing in a programming language that has good support for them like Oz ( http://www.mozart-oz.org/ ).

-bob