Re: blocked gui - threading problem?

["Milosz Derezynski" <internalerror gmail com>]

This requires more information about you code, but just off head said, it's not a good idea to call into Gtk+ from a thread without severe precautions.

Can you paste/post your thread's code and maybe also the code responsible for the drawing?

Milosz

On 7/13/07, Daniel Hornung <daniel hornung gmx de> 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