<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 10, 2021 at 4:51 AM Hal Murray via devel <<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
James Browning said:<br>
>> We need to keep in mind how to make this work in a multi threaded<br>
>> environment.<br>
> I think you would need to deglobalize some variables first. <br>
<br>
What do you have in mind?<br></blockquote><div><br></div><div>I tend to overfocus on early optimizations and other trivial<br>things. Neither of the arguments passed to read_clockstatus<br>from the converted mockup is used, instead, the variable<br>res_associd is pulled from being global.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think there is an Atomic "library" that is mostly the compiler being smart <br>
enough to recognize a few special cases.  I'm pretty sure the Intel hardware <br>
directly supports<br>
  foo += xx<br>
and hence <br>
  foo++<br>
if you use the right instructions.  So we have to use the right macros but we <br>
don't need locks.<br>
<br>
There are a few places where it might be nice to update a set of counters at <br>
the same time.  For example, the number of packets received and the number <br>
processed or dropped or ...  I'm willing to live with that fuzz on a busy <br>
system.<br></blockquote><div><br></div><div>IIRC, I saw that was mentioned as a C11, feature and not C99.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--------<br>
<br>
<br>
>> There is a slight complication.  We need the name that comes back with a<br>
>> variable to be a meaningful description.<br>
> So, drop the Millsian object notation (or whatever it is called) for<br>
> something closer to JSON? Protobuf need not apply.<br>
<br>
I'm not interested in JSON.<br>
<br>
We could add a pretty name to the table and a way for ntpq to ask for the <br>
pretty name.<br>
</blockquote><div><br></div><div>You lost me put up a mockup, please.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">------------<br>
<br>
<br>
> For example, after butchering all the following it occurred to me that one<br>
> could just ad a CB (callback) or HOOK value. I mean it is not like there is a<br>
> sudden lack of space for them. <br>
<br>
I wouldn't have called it "callback".  There is no back part.<br>
<br>
My straw man is that each slot in the table has a name (that ntpq asks for), <br>
flags, type tag, pointer to variable, and print routine.  My print routine is <br>
probably your callback.  I'm expecting that we will need a half dozen or so <br>
print routines for the common cases (int, long int, unsigned long..., float, <br>
double...) and a half dozed or so slots that need a dedicated print routine.<br>
</blockquote><div><br></div><div>Unless you make the handlers smarter I think there will be  <br>more than 6 corner cases that need extra help. It would<br>probably be best to separate the low easy corners from the<br>more difficult.<span style="font-family:monospace"><br></span></div><div><br></div>ctl_putdata and ctl_putunqstr are probably lower-level  <br>implementations than you intend.<br><br>ctl_putuint is common, ctl_putint less so. ctl_putts,<br>ctl_putadr, ctl_putrefid, ctl_putarray, and ctl_putstr are<br>also already there.<span style="font-family:monospace"><br></span></div></div>