|
|
|
|
|
|
by geogriffin
2646 days ago
|
|
|
Looks like pretty good code, but interesting that they only have a few dependencies and decided to implement a lot of stuff, like kernel polling, themselves rather than using the mio crate. I wonder why. They also implemented the noise handshake in a non-generic way tightly coupled to wireguard protocol, again written themselves instead of using an external dependency, which I think is also the approach other wireguard implementations have taken.. which is fine, but harder to independently verify. There's a lot of code there. |
|
|
Mio, in theory, is not very far off of what I ended up implementing, but it is missing a few features that I really needed, and building those features on top of Mio would be harder than just using epoll/kqueue directly. Also I don't understand the fear people have of using epoll/kqueue. Those are very basic features that every engineer has to know how to use.
So what are the features:
No locks - Mio polls under lock, but epoll/kqueue are multithread safe by nature as long as you use the correct filters. Mio has considerable overhead over pure epoll/kqueue.
No need for tokens, instead I store closure pointers. Real zero overhead. Of course I could cast pointers to usize and use as Mio tokens, but I would still have to build the ownership model on top, which is most of the work anyway.
Timers in Mio run in a thread??? I use platform idiomatic conventions instead, which with kqueue require direct access to kqueue.
Signal handlers, can't make idiomatic one with Mio (or maybe I missed how).
Same with notifications. Could use something awkward like a channel, but prefer idiomatic approach.