On Wed, Mar 10, 2021 at 4:51 AM Hal Murray via devel <devel@ntpsec.org> wrote:
> > James Browning said: > >> We need to keep in mind how to make this work in a multi threaded > >> environment. > > I think you would need to deglobalize some variables first. > > What do you have in mind? > I tend to overfocus on early optimizations and other trivial things. Neither of the arguments passed to read_clockstatus from the converted mockup is used, instead, the variable res_associd is pulled from being global. > 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 > directly supports > foo += xx > and hence > foo++ > 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 > system. > IIRC, I saw that was mentioned as a C11, feature and not C99. > -------- > > > >> 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 > pretty name. > You lost me put up a mockup, please. > ------------ > > > > 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. > Unless you make the handlers smarter I think there will be more than 6 corner cases that need extra help. It would probably be best to separate the low easy corners from the more difficult. ctl_putdata and ctl_putunqstr are probably lower-level implementations than you intend. ctl_putuint is common, ctl_putint less so. ctl_putts, ctl_putadr, ctl_putrefid, ctl_putarray, and ctl_putstr are also already there.
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
