Hal Murray <halmur...@sonic.net>:
>
> > 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.
Right. But the way to get there is certainly *not* to try to design
ahead while you're still thinking in a language like C where
concurrent programming is difficult and error-prone.
Once you get used to being able to program in Go's implementation of
communicating sequential processes you'll gave much better tools for
doing concurrency.
> > 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.
Do you know what our actual bottlenecks are? Have you [rofioled them?
> You can't put it on an ouput queue. Handing it to the kernel it is part of
> the time critical region.
I meant output *channel*. With a goroutine spinning on the end of it.
> > 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.)
Any possibility of a DDoS being feasible is interesting.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
