On Wed, 30 Mar 2011 07:15:16 +0200, Terje Mathisen wrote: > This is exactly the reason why the shm communication setup I am > currently testing has a 64-bit marker as the first field: > > (It is "GPSD-NTP" when viewed as a little-endian string.)
I suspect that there may be some compilers for 32-bit platforms that won't know what to do with a 64-bit field (declared as such). The approach I took was to use a local (i.e. non-shared) union of 4 chars and a 32-bit int, setting the 4 chars to known values and converting to host order with ntohl. That result is then put into shared memory. Doing that for both processes allows each to detect an incompatibility with the other (with shared memory for each process' word size/endianness data). In retrospect, precautions would probably have to be taken to ensure that the union was in the same page (or at least a page with the same endianness) as the shared memory. Prior to shared memory use for transfer, the union itself could be in shared memory. > Since the current testing have shown that it works with 13 M > updates/second, I feel quite safe that it will work fine for one or a > couple of timestamp messages per second. I don't expect that endianness would change during process execution, so initializing one time should suffice. In any case, I wouldn't expect a performance issue. > Bruce, I assume you follow both the gpsd and ntp-hackers mailing lists? No, though I have seen a few messages in my inbox as a result of earlier postings here ("here" being Usenet group comp.protocols.time.ntp). _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions