Re: [Alephmodular-devel] Detangling/de-Mac-ifying

[Chris P. <sf...@ma...>]

Oops, thought Reply-to was set to the list.

On May 17, 2005, at 6:02 PM, Br'fin wrote:
> In the case of AM, this is, I believe, in shell.cpp. However, as a 
> further snarl. I don't think going with a straight up abstraction, 
> like I did with some other areas of the code, necessarily gets what we 
> need out of it. The process of updating the state of the world and 
> rendering it happens in this event loop. So I want to add a thread in 
> here. But I don't know enough about threads to get my brain too well 
> around them either.

Just to clarify, is the thread you'd like to add would be responsible 
for the rendering? i.e. an update to game state would trigger an update 
to audio/visual state, and the audio/visual state would update at the 
same time as the next game state update.

I've had some limited dealings with threads before, in the form of 
boost::thread (this was on Linux), although I used my own mutexes since 
I didn't quite understand their documentation. However, I'm not sure 
exactly what the best way to split two event loops apart would be - 
after all, I believe that you would need to create a readable state for 
the display loop that would be entirely separate from the writable 
state of the game loop.

For reference, a couple relevant boost classes are:
http://www.boost.org/doc/html/thread.html
http://www.boost.org/doc/html/barrier.html

...and the Mutex explanation is here:
http://www.boost.org/doc/html/threads/concepts.html

Using Boost.Threads right out of the bag is an option; so is taking a 
peek at the source code and reimplementing it for AM. Using boost 
directly is probably a better option, though, as the boost libraries 
are likely to get adopted fairly directly into the C++/0x standard, and 
that would mean that we would have a pretty standard base of support 
for threads.

I also find it ironic that the first three people on a thread about 
"de-Mac-ifying" have mac.com email addresses :)

- Chris Pickel