On Fri, 18 Mar 2011 05:17:32 +0000, Harlan Stenn wrote: [referring to a proposal to somehow combine SVID shared memory and POSIX shared memory code in a single driver] > I think I've seen these and I still don't think it's a big deal.
Perhaps you are confused because both contain the words "shared memory"? They access different objects existing in different namespaces using different methods accessed via different APIs. They really have nothing in common. > OK. I sure know about SVID semaphore mechanism. The semaphore (or > mutex) operations *must* be nonblocking. As I never said anything about blocking, I wonder why you bring this up? >> 4. Assuming specific sizes for an integer is a really bad idea... "(64 >> bits making up the) clockTimeStamp* and receiveTimeStamp* fields" > > I'm missing your point here. We should only be using "generic" integral > types if we have reason to believe they are at least N bits wide. For > anything else, we are using intNN types (for cases where we want exactly > NN bits). Perhaps you should look at the refclock_shm.c code; that's *entirely* '"generic" integral types'. I.e. nothing specifies that those fields comprise a 64-bit chunk of memory (shared or otherwise). [and if one changes the existing generic types, it will break on one architecture or another] _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions