Re: [Bug-gnubg] Anomolous looking code in eval.c

[Gary Wong]

On Tue, Jul 16, 2002 at 05:19:11PM +0200, Jim Segrave wrote:
> On Mon 15 Jul 2002 (18:37 +0000), Joern Thyssen wrote:
> > I've tried to implement something similar to a tutor-mode, but had some
> > trouble with the GTK interface. While the program is analysing the human
> > player's moves, GTK is "frozen", but remembers your mouse clicks, and goes
> > totally bananas after finishing the analysis if you've clicked around
> > while waiting for the analysis to finish.
> 
> Thanks - that should be helpful. The remembered mouse-click issue is
> just the sort of thing I needed to hear about. I guess I'd better read
> up on the gtk documentation to see if there's some way to tell it to
> drop unprocessed events or something.

Unfortunately this area is full of subtleties.  The best place to see
the deep magic is in the function HandleXAction() in gtkgame.c, but
there are some unavoidable repercussions in many other parts of the
program.  The essential idea is that when gnubg is idle, it is
responsive to both TTY and GUI activity.  When it is busy, it
generally ignores TTY activity (which will be buffered), and handles
some GUI activity (e.g. it handles display updates, but ignores most
user input).  Keyboard interrupts and the GUI "stop" button are always
active: keyboard interrupts are dealt with by installing a signal
handler for SIGINT, and the "stop" button is designated as the GTK
grab widget.  The interrupt/stop handlers are very simple, because
they can be executed more-or-less asynchronously, so we have to
guarantee that they are safe.

If all goes well, this design should ensure that we avoid any unwanted
reentrancy caused by user input while other processing is in progress.
The assertion on fComputing in NextTurn() in play.c should catch the
worst case reentrancies if there is a mistake somewhere.

It is possible that the auto-analysis problems could be fixed with
something as simple as ensuring that the "stop" button has the grab in
autoAnalyseMove(), but as always, the devil is in the details.  I'll
look into the problem this week.

Cheers,
Gary.
-- 
   Gary Wong           address@hidden           http://www.cs.arizona.edu/~gary/