Re: blocked gui - threading problem?

[Robert Caryl <bob fis-cal com>]

I am guessing that your method PlayerWindow::getMove with its nice tight little loop is the culprit.  You need to allow the main loop to iterate if it has events (like redrawing stuff) pending from within your wait loop.

Bob


Daniel Hornung wrote:

Hello everyone!
I have the following problem, I hope I can make myself clear (I'm quite new to 
gtkmm, so maybe my problems seem trivial to you).  I have written a small gui 
for a little board game, which most times works fine.  But sometimes the 
windows aren't redrawn when they should, everything just hangs and "painted 
over" areas are simply gray.

This is the basic layout of my program:

For each player there's a 
class PlayerWindow : public Gtk::Window 
which draws the board and receives events.  It has two main methods, "void 
update(Move& lastMove)" for updating the board and "Move* getMove()" for 
returning a new move.

Then there's one class ("Board") managing the whole game with pointers to the 
two players which in sends the current moves to both players and asks each of 
them for their next move, it works quite like 

while(game is still running){
  player1->update(move); 
  player2->update(move);
  move = player1->getMove();
  // do stuff with move
  player1->update(move); 
  player2->update(move);
  move = player2->getMove();
  // do stuff with move
}

For starting the game (and allow for graphical setup actions) I also have one 
window ("GameWrapper") which connects the following method to a button being 
clicked:

void GameWrapper::startGame()
{
  cout << "Game will be started\n";

  Glib::thread_init();
  startGame_T = Glib::Thread::create
    (sigc::mem_fun
     (&myBoard, &Board::startGame),
       true);	
  
  cout << "Game started\n";
}

Thus the Board can ask the two PlayerWindows for moves without halting all the 
GUI.  The calls to the PlayerWindows happen strictly one after the other.  
Still, could my problem be with this construction?

Or could it have to to with the getMove() method which only returns a Move 
once it's been entered?  Simplified, it works like

Move* PlayerWindow::getMove()
{
  // connects some methods so that mouse clicks (on a widget called 
  // "input") will be recognized as Moves
  askMove();

  while(input.waitForInput()){
    // wait for 0.2 seconds
    Glib::usleep(200000);
  }

  // now we can get the next Move
  return input.getMove();
}

To be honest I have no idea as to why it sometimes hangs and sometimes not...  
Comments (also if i should have chosen a completely stupid overall design) 
and help are highly appreciated.

Thank you in advance,
Daniel
  

_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
  

--

Robert L. Caryl Jr.
Fiscal Systems, Inc.
102 Commerce Circle
Madison, AL 35758-2706 USA
256-772-8922 ext. 108

This e-mail message may contain privileged or confidential information. If you are not the intended recipient, 
you may not disclose, use, disseminate, distribute, copy or relay this message or attachment in any way. 
If you received this e-mail message in error, please return by forwarding the message and it's attachment 
to the sender and then delete the message and it's attachment from your computer.

Neither Fiscal Systems, Inc., nor its affiliates, accept any liability for any errors, omissions, corruption 
or viruses in the contents of this message or any attachments that arise as a result of e-mail transmission.