[Top][All Lists]

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

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

From: Olivier Baur
Subject: Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS
Date: Sat, 31 May 2003 13:37:58 +0200

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.

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

reply via email to

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