Re: [pygame] fork() and PyGame?

[Michael <mogmios@mlug.missouri.edu>]

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


--
"When Government fears the people, it's liberty. When people fear the
Government, it's tyranny."                   -- Benjamin Franklin

Michael <mogmios@mlug.missouri.edu>
http://kavlon.org