[Top][All Lists]

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

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

From: Joern Thyssen
Subject: Re: [Bug-gnubg] Main window blocked whilst analysing
Date: Wed, 10 Dec 2003 12:29:36 +0000
User-agent: Mutt/1.4.1i

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? 


PS! I hope noone in California is reading this. I understand that the
terms master and slave are forbidden there?!

Attachment: pgpKKBbanlFUn.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]