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

[Jim Segrave]

On Wed 10 Dec 2003 (12:29 +0000), Joern Thyssen wrote:
> On Wed, Dec 10, 2003 at 12:04:01AM +0100, Jim Segrave wrote
> > > 
> > > 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.
> 
> I'm not very familiar with neither sockets nor multi-threading, so my
> questions may be stupid :-)
> 
> Anyway, doesn't this require still multi-threading? How would you handle
> the communication with the slaves? You call "write" to tell the slave
> what to do, but how do you receive the answer -- doesn't it require you
> to have a thread running "read" on the socket? 

You do a select with a short timeout whenever you are interested in
checking if there is return data ready - the timeout can be set in
microseconds. You pass a bitmask of the file descriptors for the
sockets of interest (one for read, one for write, one for outofband
exceptions). It returns the number of descriptors which are ready for
read or write and handles interrupted system calls neatly. Since you
get to choose when you want to read/write from the socket, you don't
get the same complexity or need for semaphores and locks that a
threaded solution requires.


-- 
Jim Segrave           address@hidden