Re: blocked gui - threading problem?



Hey Daniel,
Is there any particular reason why you need the extra thread? Can't you
just connect handlers to the input events and process the moves
immediately, or does it reqire lenghty calculations? If
"player1->update(move);" call doesn't take longer than a couple of tens
of milliseconds you might be better off using no threads.
I can't tell you why you're having the gui problems, but it might well
be caused by your worker thread calling GUI functions... (and it might
occur only if the timing between the main and worker thread is in a
certain way, ie not always as you describe it)
Regards, Klaus


On 13/07/2007 16:37, 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
>   
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 15.07.2007 14:21
>   




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]