Using Go for NTPsec

[Hal Murray]

>> You have a new toy.  The only tool needed is a simple lock.
> Oh? What about the concurrent DNS thread we already have?

The only reason we have a DNS thread is because the current code only has one 
thread.  If we had a thread per "server" in the config file, they could do DNS 
directly.

My comment about a simple lock was in reference to the client side providing 
data for the server.  A simple lock seems appropriate to me but I would be 
happy to learn about something better.  A channel doesn't seem appropriate 
since there isn't any thread to listen to a channel and if you invent a 
thread, you still have the problem of getting the data from that thread to the 
server threads.


> You're thinking in C. This is a problem, because mutex-and-mailbox
> architectures don't scale up well.  Human brains get overwhelmed at about 4
> mutexes; beyond that the proliferation of corner cases get to be more than
> the meat can handle.

I'm missing something.  What is the problem with lots of mutexes?  I'm 
guessing you are thinking of deadlocks.  They don't happen if code running 
with the lock held doesn't call any code that needs another lock -- a leaf 
node in the tree.  I think my brain can handle lots of leaf nodes.

Does Go have any utilities to scan code and build the lock tree?

How do you avoid analogous deadlocks with channels?  I'm guessing that the 
simple case of code that does read from channel1, process info, send on 
channel2 is equivalent to a leaf lock.

---------

> 1. Wait on the inmput channel for a packet to send.
> 2. Turn off GC
> 3. Timestamp the packet.
> 4. Ship the packet
> 5. Turn on GC
> 6. Loop back to 1.

I'm guessing that you think the mutex/lock I'm interested in is to protect the 
no-GC flag.

What is the cost of a lock vs a channel pass?  Given that the channel needs to 
schedule another thread, I'll guess that costs significantly more.

The lock I'm actually interested in is the one that protects the data that the 
server thread needs to fill in the packet.  We need that even if we aren't 
messing with the no-GC flag.

There is another problem with your proposal.  You skipped step 3.5, do the 
authentication.  We need several CPUs working on that step in order to keep up 
with a gigabit link.


-- 
These are my opinions.  I hate spam.