Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS

[Joern Thyssen]

On Sat, May 31, 2003 at 03:52:14AM +0200, Olivier Baur wrote
> 
> Could you try it on a multiprocessor machine or with remote slave 
> hosts? (in tty mode)
> 
> Starter info:
> - the multiprocessor and remote processing mechanism is implemented as 
> "processing units" ("pu" for short)
> - procunits can be either local (1 per processor) or remote (1 per 
> remote host); each remote host in turn can sport several local and 
> remote procunits
> - all commands related to procunits are "pu <sub-command>", "set pu 
> <sub-command>" or "show pu <sub-command>"; gnubg "help" will give more 
> details;
> - type "pu add local" to add an extra local procunit (1 is created by 
> default at gnubg startup time; if the GetProcessorsCount() in 
> procunits.c is properly implemented for your system, gnubg will create 
> as many local procunits as there are processors)
> - type "pu add remote a.b.c.d" to add a remote procunit; the remote 
> procunit must be running gnubg in slave mode on host at ip address 
> a.b.c.d
> - to run gnubg in slave mode, type "pu slave"
> - other useful commands: "show pu info" (or "pu info"), "show pu 
> stats", "pu start <id>" and "pu stop <id>"

By hacking GetProcessorsCount to return 5 I emulated an 5-way SMP
machine. That worked fine :-)


The remote pu was a bit more tricky. Perhaps there are some subttle
differences between Mac and unix?! I'm no socket-wizard, so I just did
some trial-n-error :-)

For the slave to work:

First, I removed the SO_RCVTIME0 and SNDTIME0 options on the sockets.
According to my man page:

       SO_RCVTIMEO and SO_SNDTIMEO
              Specify the sending  or  receiving  timeouts  until
              reporting  an  error.  They are fixed to a protocol
              specific setting in Linux and  cannot  be  read  or
              written.  Their functionality can be emulated using
              alarm(2) or setitimer(2).

Apperently they have to be protected by some #if LINUX directive.


For the master I changed:

remoteAddress.sin_addr.s_addr = htonl(ppu->info.remote.inAddress.s_addr); 

to

remoteAddress.sin_addr.s_addr = ppu->info.remote.inAddress.s_addr;

THat is, removed the call to htonl. inAddress is already calculated
using inet_aton so it must be in network byte order already. So no need
to call htonl. 

This seems to work. 

BTW, I get a gazillion compilers warnings in
procunits.c. Is there a -Wall compiler option on Mac?

Jørn