[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnome-devel-list
Subject:    Re: How to maintain responsiveness during long functions?
From:       Owen Taylor <otaylor () redhat ! com>
Date:       1999-06-28 4:57:25
Message-ID: ybewvwoylai.fsf () fresnel ! labs ! redhat ! com
[Download RAW message or body]


Ian Peters <itp@gnu.org> writes:

> Hello,
> 
> Recently, two people have sent me some very good reversi algorithms
> for inclusion into iagno.  Since many people have complained about the
> skill level of the computer players (very low), this is a good thing.
> However, obviously both algorithms need to spend a good bit of time
> thinking, and currently, this means that the game does not respond (ie
> menus, redraws, etc are not handled) until the computer makes its
> move.
> 
> What is the `proper' way to handle this?  Is there any simple way to
> tell it to process any pending events at critical junctions in the
> algorithm, or do I have to either restructure the algorithms to work
> through with the gtk event system, or make the application threaded?

As people have mentioned, you can periodically check
for events.

(The "modern" way of doing this is:

 while (g_main_iteration(FALSE))
   /* Nothing */;
)

If this is not sufficient, I would suggest splitting
the program into front-end/back-end. Since reversi
is stateless, you can do this easily enough. The protocol 
would look something like:

Frontend: (color of player and current board position)
BLACK ----B---W---B-WW---BBWB--
Backend: (next move)
2,3
 
Combined with a io handler, this makes it very 
easy to make the front end responsive, and write
the backend in a simple fashion.

Cancellation (for instance, if the user hits the
undo button while the computer is thinking) is easy -
you just kill the current backend process and
start a new one.

Regards,
                                        Owen

[prev in list] [next in list] [prev in thread] [next in thread]