Re: multithreaded strategy boardgame

[Havoc Pennington <hp redhat com>]

Adrien Treuille <treuilla@gusun.georgetown.edu> writes: 
> 1 - Is there a way of finding out the width and height of a
> GdkPixmap? I'm

gdk_window_get_size() is actually gdk_drawable_get_size(), confusion
is fixed in GTK 1.4 but the function works in 1.2.
 
> 2 - How would one implement multithreading in gtk? (I'm a java programmer,
> and new to threads in c/linux.) One solution seems to be LinuxThreads
> (i.e. #include <pthreads.h>), and another seems to be gdk threads... Are
> these two the same or not? If not which one would you recommend? Perhaps
> something else? I'd like to be able to accomplish interthread
> communication without using global variables. Also, where can I find good
> sample code to learn how to do all this stuff.
> 

The glib threads stuff doesn't let you create threads, it is only a
portability layer for locking. That is, it's just enough
cross-platform support to let you lock the GTK GUI.

I'm pretty sure on Linux you want to use POSIX threads (aka pthreads),
I think these are different from LinuxThreads. pthreads are the
closest thing to portable threads, though they are weird or broken on
plenty of UNIX flavors.

> Regarding the second question: I'm writing a strategy board game like
> chess called Lines of Action
> (http://www.andromeda.com/people/ddyer/loa/loa.html). I'm hoping to
> implement the AI module as a seperate thread. The thread would evaluate
> positions the whole time. When the user makes a move the AI thread would
> be given a time limit before which it has to make a response move. The AI
> module's move would affect how the board looks, so the AI thread has to
> interact safely with the GUI thread. Hope that helps.
> 

You _can_ have the AI thread lock the GUI, modify the GUI, then unlock
the GUI, but in general you get a more robust and less buggy
application if you treat the AI thread as a separate process and talk
to the GUI via a pipe. Use gdk_input_add() or g_io_add_watch() to add
a callback listening to your pipe to the GTK main loop, it's quite
convenient. This way you can ignore locking issues. 

In fact you can even use a process instead of a thread, which is
pretty much just as efficient on many systems (such as Linux), and is
much safer and more portable than threads.

Of course if you need to pass large chunks of data between the AI and
the GUI, instead of simple messages, there can be big advantages to
threads.

Havoc