Using Go for NTPsec

Hal Murray halmurray at sonic.net
Fri Jul 9 09:47:01 UTC 2021


More topics for this discussion:

What platforms is the new environment supported on?  See my reply to Sanjeev 
Gupta's message.

As far as I can tell, we don't have a list of supported/tested platforms.  Is 
there an official we page that describes what we support?  (I'm expecting 
something like POSIX-enough.)

--------

In addition to the barrier to entry, there is also the barrier to re-entry.
  Friends mentioned it as a disadvantage of python.  It's a pain to work on 
code that you haven't worked on for a while.
  I can confirm that.  I find ntpq hard to work on.

There is a bug in our ntpq, or was not-that-long-ago and I'm pretty sure it 
hasn't been fixed.  The problem is recovering from lost packets.  If it's 
collecting a batch of packets and one gets lost, it returns none rather than a 
partial clump up to the lost packet.  A couple layers up when it should be 
dropping the size of the clump it goes off on another path and just tries 
again.

It would be interesting to poke around and see if that bug was in the original C version or if the bug was introduced when translating to python or while working on the python version.

------

> I know more about the problems around getting to a memory-safe language after
> this conversation than I did before it, and that is excellemt.

You use "memory safe" often enough without actually discussing what it covers.  I sometimes wonder if there are other properties we should be considering.

I put near-optimal performance high on the list.  My attempt at some simple Rust timing code got surprisingly high numbers for reading the clock.  It may have been loop overhead.  Manually replacing an iterator style loop (the clean way) with an ugly by-hand counter got somethig reasonable.  I haven't tried to figure out what is/was going on.  (yet)

--------

> I gave up the experiment when I discovered that Rust had no equivalent of
> poll(2)/select(2). 

I poked around a bit and didn't find anything that looked good.  I assume you wanted to wait for network data.  Did you consider a thread per socket?

My experience is that my experiment of similar trivial size was a success.  Was that because I picked a problem area that was easier in some measure, or maybe I just got lucky and all the library support I needed was already there.

It was slow, very slow, to find/understand what I needed but it felt like I would pick it up.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list