Bruce wrote: > On Thu, 17 Mar 2011 19:57:02 +0000, Harlan Stenn wrote: > > > Please see http://support.ntp.org/bin/view/Dev/RefclockShmV2 > [...] > > I'm curious if we can support both POSIX and SVID SHM from the same > > codebase, and use a flag bit or a mode to select which one is used. > > OK, looked at it and the bug it references. Comments: > > 1. one code base is probably impractical (see separate response to Dave > Hart's post).
I think I've seen these and I still don't think it's a big deal. > 2. What's needed to coordinate driver and shared memory client access is > a proper semaphore or mutex, not more modes to avoid doing the job > properly. For crying out loud, Dijkstra's semaphore paper is now ca. 46 > years old: > http://en.wikipedia.org/wiki/Semaphore_(programming) > http://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD123.html OK. I sure know about SVID semaphore mechanism. The semaphore (or mutex) operations *must* be nonblocking. I do not know why folks have avoided this in the past. I'd be curious to know why. > 3. to get nanosecond timestamping on a non-proprietary platform implies > use of (POSIX) clock_gettime() or something like it, which uses (POSIX) > struct timespec. If one has those, one likely also has POSIX shared > memory and POSIX mutexes and semaphores. Mixing POSIX and SVID seems > like a bad idea; at some point, the SVID-specific stuff is going to go > the way of Lotus-1-2-3 (and I say that as a long time user of genuine > UNIX (Registered Trademark) System V). I'm not worried about this. When SVID dies, it dies. It hasn't been all that long that we deprecated K&R C compilers. > 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). H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
