| I have been getting the mio question a lot. 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. |