Using Go for NTPsec

[Hal Murray]

> How do you know something is a leaf node?  Lock claims can be arbitrarily
> fall down a call chain, after all. 

I was thinking of looking at the code.

In the context of passing data to server threads, the code will be only a 
page.  There are 2 routines:

static: data

  update_info (new):
    lock_write
    data = new
    unlock

  get_info:
    lock_read
    temp = data
    unlock
    return temp

Note that there are no calls.  It's got to be a leaf node.

-------

> I don't know why this is.  The Go designers did something subtle that I don't
> understand, and nobody else seems to either.  I have researched this because
> I find it puzzling and interesting, and not found any plausible theory. 

Thanks for your comments on this area.

>  Normally the work you will do per
>   item will greatly exceed the 90–250 ns it takes to move the item
>   through the channel, so it’s just not worth worrying about.

That sounds like the right ballpark.  Again, if I were working in this area I 
would be writing hack code to generate numbers.  It's got to have a buffer for 
each item waiting in the channel.  Does it do an alloc/free on each item or 
does it avoid that by saving the buffer and reusing it?  We have 3 sizes of 
packets: no-auth (48 bytes), shared-key (68), and NTS (232).  Can we tell it 
how much to copy or will it copy worst-case?

Processing a packet takes a few uSec for no-auth and ~10 usec for NTS.  A 
single 250ns is not important relative to 10 usec but will be significant 
relative to a few usec if you do it several times per packet.

---------

I still haven't seen how you plan to get the data from the client side to the 
server side without a lock.  See sample code above.

The server side does:
  loop:
    recv_request
    get_info
    fill in reply
    send_reply

I suppose you could do it if channels have a peek option. That will take a lot 
more code.  You will need a main channel and a sub-channel per thread and 
another thread to copy over.  And then you have to handle the case where a 
server thread is idle so it's not checking its new-data channel...  Ugh.



-- 
These are my opinions.  I hate spam.