[pygame] fork() and PyGame?

[Michael]

Does fork()'ing code not work with PyGame? I tried to fork() my
application code from the UI code and the events posted by the
application code weren't being picked up by the UI. Am I right in
thinking that this method just doesn't work or is there something else
I'm doing wrong? Thanks.

[Pete Shinners]

Post by Michael
Does fork()'ing code not work with PyGame? I tried to fork() my
application code from the UI code and the events posted by the
application code weren't being picked up by the UI. Am I right in
thinking that this method just doesn't work or is there something else
I'm doing wrong? Thanks.

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.

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?

[Michael]

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.

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. :)

[Bob Ippolito]

Post by Michael

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.

Post by Michael

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