Re: [Bug-gnubg] Main window blocked whilst analysing

[Jim Segrave]

On Tue 09 Dec 2003 (20:53 +0000), Richard Buckle wrote:
> At 12:57 pm +0100 9/12/03, Ralph Stoesser wrote:
> >-----Original Message-----
> >From: Joern Thyssen [mailto:address@hidden
> >Sent: Tuesday, December 09, 2003 9:15 AM
> >To: Ralph Stoesser
> >Cc: address@hidden
> >Subject: Re: [Bug-gnubg] Main window blocked whilst analysing
> >
> >
> >On Tue, Dec 09, 2003 at 01:26:13AM +0100, Ralph Stoesser wrote
> >>
> >>> What's the problem with the current design respective to
> >>> multithreading?
> >
> >>It's a long story, but gnubg is basically not designed for
> >multithreading, and it's not simple to change. For a
> >>starter, the GUI toolkit GTK+ we use, is buggy when multithreading.
> >
> >>Go through the mailing list archive and search for multithreading or
> >"background analysis" or similar.
> >
> >>J?rn
> >
> >Thank you, J?rn. I have found some threads about it and read those.
> >Personally I believe that it is worth nearly _every_ effort to try to
> >make gnubg a multithreaded app, since there would be so many advantages.
> >For an up-to-date program with a very nice GUI (and the new paneled
> >gnubg GUI _is_ very nice) this is a must I think.
> >
> >I'll try to play around with GTK+ and multithreaded programs now after
> >I've read the GTK+ FAQ regarding multithreading. Since I'm new to GTK+
> >this may take a while. Maybe after this lesson I will try to change
> >gnubg so that it evaluates in a separate thread.
> >
> >Best regards,
> >Ralph
> 
> Maybe it would be simpler to have the GUI simply spawn a GUI-less
> instance of gnubg to perform the analysis on a copy of the match
> file? That would keep the GUI responsive, and dual-CPU machines would
> get some benefit too.

I may seem like a fanatic on this subject, but connecting to one or
more analysis processes via network sockets is far better than
multi-threading - it works on single CPU, multi CPU and of course
clusters of machines. It scales to match the number of machines you
want to tie up. It is free of locking issues. And, best of all, it's
easier to implement than almost any other approach.

-- 
Jim Segrave           address@hidden