Using Go for NTPsec

[Hal Murray]

> We don't have a multithreaded server yet.  Worst case we have two threads,
> and only one can ever reach the critical region in question. Don't borrow
> trouble! :-) 

I'm interested in building a server that will keep a gigabit link running at 
full speed.  We can do that with multiple threads.


> If we go to using threads more heavily, the idiomaric Go way to handle this
> problem would be to have a queue that does only the code in window 1.  When
> you write to the request queue, it would stop GC, do time-critical magic,
> restart GC, and ship the result on the output queue. 

That's adding a bottleneck that we need multiple threads to avoid.

You can't put it on an ouput queue.  Handing it to the kernel it is part of 
the time critical region.


> I'm not worries about a DDoS. I don't think the protocol machine gives a
> hostile client or server any way to force hitting that window. 

I'll work up some numbers if you think that will be interesting.  (It will 
take a while.  I have to put a system back together.)

This is a good example of where we are wasting time discussing things because 
there is a GC we (might?) have to dance around.

-- 
These are my opinions.  I hate spam.