ntpq meets log files
hmurray at megapathdsl.net
Wed Mar 10 12:51:16 UTC 2021
James Browning said:
>> We need to keep in mind how to make this work in a multi threaded
> I think you would need to deglobalize some variables first.
What do you have in mind?
I think there is an Atomic "library" that is mostly the compiler being smart
enough to recognize a few special cases. I'm pretty sure the Intel hardware
foo += xx
if you use the right instructions. So we have to use the right macros but we
don't need locks.
There are a few places where it might be nice to update a set of counters at
the same time. For example, the number of packets received and the number
processed or dropped or ... I'm willing to live with that fuzz on a busy
>> There is a slight complication. We need the name that comes back with a
>> variable to be a meaningful description.
> So, drop the Millsian object notation (or whatever it is called) for
> something closer to JSON? Protobuf need not apply.
I'm not interested in JSON.
We could add a pretty name to the table and a way for ntpq to ask for the
> For example, after butchering all the following it occurred to me that one
> could just ad a CB (callback) or HOOK value. I mean it is not like there is a
> sudden lack of space for them.
I wouldn't have called it "callback". There is no back part.
My straw man is that each slot in the table has a name (that ntpq asks for),
flags, type tag, pointer to variable, and print routine. My print routine is
probably your callback. I'm expecting that we will need a half dozen or so
print routines for the common cases (int, long int, unsigned long..., float,
double...) and a half dozed or so slots that need a dedicated print routine.
These are my opinions. I hate spam.
More information about the devel