bug-gnubg
[Top][All Lists]
Advanced

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

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


From: Joern Thyssen
Subject: Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS
Date: Sat, 31 May 2003 11:00:35 +0000
User-agent: Mutt/1.4.1i

On Sat, May 31, 2003 at 12:13:09PM +0200, Olivier Baur wrote
> 
> Le samedi, 31 mai 2003, à 11:23 Europe/Paris, Joern Thyssen a écrit :
> 
> >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.
> 
> Okay. So I'll set a timer if LINUX is set instead of setting a socket 
> timeout. It should do the job.

Linux uses a predefined timeout. I think that's fine. I've just #if
__APPLE__'ed the code. I don't see any need for alert and settimer; the
standard timeout should be fine.

> BTW, talking about byte ordering, I'll have to do some work to have the 
> data exchanged by remote processing units (rpu_message) be in a 
> platform independent format (for now, rpu's basically exchange structs, 
> which will work only between platforms which have the same byte 
> ordering and the same struct field alignment)

In principle the best would be to transfer struct in ASCII, since this
is the easiest to debug. It's probably also the most flexible, but may
require a lot of coding.

The alternative is to always transfer data in, say, big endian.

Jørn




reply via email to

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