Re: [Bug-gnubg] GNUbgW pagefault_speedingup50%

[Joern Thyssen]

On Thu, Jun 27, 2002 at 08:34:21PM +0200, sev_notrump wrote
> 
> > > The following pagefault happened when the program was idle. It was my
> > > move and i ordered for a T  :)
> > 
> on  Thursday, June 27, 2002 7:53 PM Joern Thyssen wrote
> 
> > Can you be more specific?
> 
> I was making a cup of tee . It was my move. When i came back i saw a
> Window message containing the page fault

I have no idea what's happening. Øystein, have you seen something like
this before?

> > On Tue, Jun 25, 2002 at 08:03:27PM +0200, sev_notrump wrote
> > 
> > > A suggestion to speed up analyses by at least 50 % 
> > > 
> > > Scenario  player A GNUbg
> > >                 player B HUMAN                 
> > > 
> > > B intends to play against A and after that he wants to analyse the game 
> > > wit the same settings.
> > > Now ( i hope) it must be easy to implement to save  the information which 
> > > led to the move 
> > > played by A. After the dice are rolled for player B , its normal to think 
> > > a little about the move to play .During this "ïdle" time, the program can 
> > > start analysing the moves allready played  by B.
> > > When the game is finished the program has all the data of A's moves and 
> > > allready part of B's
> > > 
> > > To do:  a : create a new menu item 
> > >             b : implement the suggestions discribed above :)
> > 
> 
> on: Wednesday, June 26, 2002 2:48 PM Joern Thyssen wrote
> 
> > It's not that simple. It probably requires multithreaded programming
> > with all the problems that comes with that.
> > 
> > Multithreaded programming is one of the areas I'm currently looking
> > into, but don't expect anything soon.
> 
> Saving the data which led to a move has nothing to do with
> multithreads.Besides of that windows is doing the multitreading for
> you. 

I don't think windows some any multithreading automatically. It does
some primitive form of multi-tasking, which is not the same.

> You can also create your own threads.  I allready simulated it.
> Scenario:   player A GNUbg player B HUMAN                 
>  
>                If player A or B hase made a move scroll back to the previous 
> played move and click Analyse, analyse move . 
>                Now continue the actual game, after some time , depending on 
> the analyse parameters  the  Annotations 
>                Window contains the analyses .

Yes, that's true, but if you don't do it multithreaded then gnubg will
be busy analysing the move, and player B cannot move the chequers or
anything else until gnubg has finished the analysis. He can only look at
the position. In conclusion, I need two threads: one doing the analysis
in the "background", the other responding to the users actions (if any).

> P.S. For privacy reasons i think it's not a good  ID to write my players nick 
> from some side. Would y be so kind
> to change my name in the Credits Doc to "W.Stroop (Rob )"  ?

Done.

BTW, can you reply to the list as well, please, so they can follow or join the
discussion?

Jørn

-- 
Joern Thyssen, PhD
Vendsysselgade 3, 3., 9000 Aalborg
+45 9813 2791 (private) / +45 2077 2689 (mobile) / +45 9633 7010 (work)