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

[Olivier Baur]

Le samedi, 31 mai 2003, à 13:00 Europe/Paris, Joern Thyssen a écrit :

> > 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.

Oh, right -- there's already a defautl timeout, so, true, no need for 
alert and setitimer.
Still, I'll need to change something, because the RPU_SendMessage() and 
RPU_ReceiveMessage() functions' timeouts are currently counted as 
socket timeouts; ie, calling RPU_SendMessage with timeout = 5 will have 
it return with a timeout error after 5 socket timeouts have occured -- 
yes, rather weird way of doing things ;-) I think I'll simply go back 
to regular absolute-time timeouts.


> > 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)


-- Olivier