> 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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
