Re: multithreaded strategy boardgame

[Paul Barton-Davis <pbd Op Net>]

>I'm pretty sure on Linux you want to use POSIX threads (aka pthreads),
>I think these are different from LinuxThreads. pthreads are the

Not so. LinuxThreads are an implementation of POSIX threads. Like most
implementations, they don't fully adhere to the P.1003 standard, but
are close enough that any decent book on pthreads will work as a guide
to programming with them. They are called LinuxThreads because the
implementation uses the clone(2) system call rather than a more
generic POSIX-based mechanism, but as a pthreads-API user, you don't
have to worry about this detail.

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

I fully endorse Havoc's position on this, having written several
substantial Gtk-- based applications that include up to 6 running
threads. All of my applications use a pipe to make requests to the GUI
thread; no other thread *ever* makes a direct call to GTK. Its fast,
efficient, and totally safe. With Gtk--/C++, I have this all wrapped
up as an abstract base class; specific programs just implement a
couple of functions ("setup_windows()" for example), and the base
class takes care of the whole pipe/request handling thing.

--p