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

[Joern Thyssen]

On Sat, May 31, 2003 at 01:37:58PM +0200, Olivier Baur wrote
> 
> Le samedi, 31 mai 2003, à 13:00 Europe/Paris, Joern Thyssen a écrit :
> 
> >>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.
> 
> True.
> But it may be much better for cross-platform compatibility, especially 
> when exchanging floats (?)
> 
> 
> >The alternative is to always transfer data in, say, big endian.
> 
> But then, we still have the problem of struct fields. That is, you 
> can't byte-order a struct as a whole; you still must byte-order every 
> single field struct that's being packed into a message (including 
> structs used in structs....), which should be about the same amount of 
> work as converting to ASCII.
> And then, there's the "update risk": if someone adds a new field to an 
> existing struct (rollout_context, movefilter, cubeinfo, ...), then we 
> must ensure that the message packing/unpacking routines are properly 
> updated. And that an older version of gnubg will refuse to talk to the 
> "updated" gnubg, ie we must ensure that the message version is changed 
> in the updates gnubg (#define RPU_MSG_VERSION in procunits.h)

Hmm, right. So there is no way out: the transfer must be in ASCII.

The best is probably some keyword-value interface, e.g.,

MSG_VERSION=0100
TYPE=hello
MESSAGE=woo hoo

or perhaps XML, e.g.,

<?xml version="1.0">
<gnubg-procunits version="0100" type="hello">
   <message>woo hoo</message>
</gnubg-procunits>


The keyword-value interface is probably the easiest to code, but the XML
interface is the most extensible and it supports nesting.


BTW, I've commited some autoconf magic: PROCESSOR_UNITS is defined by
configure if pthreads is available. Also some magic in Makefile.am to
make makeweights, makehyper, and makebearoff link.

Jørn