Hal Murray <halmur...@sonic.net>: > > I'll start the ball rolling with this big one: It's time to move out of C. > > I want to threadify things, and taking advantage of that, I want to run at > full wire speed on a gigabit link with a modest server class CPU. > > I have test code running. I'm pretty sure it will work. But my test code is > in C. > > Are other people happy with threads?
I am now. Working with Go for the last couple of years has nrought me up to speed on that kind of programming. > I think threadifying things will allow us to clean up the code a lot. I > think > that may be as important for writing safe/clean code as moving out of C. I think you are right. However, I'm pretty sure we should change languages before we threadify. Both Rust and (especially) Go have concurrency primitives that are *far* more tractable than their rough C equivalents. > > My choice for a language to move to would be Go. > > The only other choice I've seen seriously mentioned is Rust. How do they > compare for thread support and for CPU cycles? Do they have full access to > all the options for network I/O? (for example recv time stamps) > > My first reaction is that I don't want reference counted stuff involved with > network I/O. But maybe that is bogus. It's roughy 5 microseconds for a > recv/send pair in C. We should write some test code so we can get some real > timing numbers. There are two major issues with Rust: 1. We have at least two people who are expert Go programmers - Ian and myself. We have nobody, AFAIK, who is up to speed on Rust. Moving the code will be a large amount of work - I don't think any good purpose is siolved by adding "learn to be fluent in an entire new language" on top of that. 2. I don't think Rust is as yet stable enough for our purposes. The language and core libraries are still in some flux - we can't yet count on a feature we're relying on not disappearing over the next decade. This is a very srtark contrast with Go's ironclad forward-compatibility guarantee. For me, issue #2 is the real dealbreaker. As for your questions: Both languages have reasonable threading support, far better than C's. Rust would be more abstemious of processor cycles than Go is, but I dont believe the difference is significant for our deployment. Full access to all aptioons for betwork I/O: I believe pure Go can be beaten into this, but that corner of the API is very poorly documented so I don't know exactly how yet. We have the option of using cgo and writing small C extensions to gety at things the Go API doesan't suppport. I don't knpw of anuy direct support for things like recv time stamps in Rust. But Rust also has a facility to call C extensions. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel