from Hacker News

Evio – Fast event-loop networking for Go

by Acconut on 11/4/17, 10:18 AM with 65 comments

  • by tidwall on 11/4/17, 2:23 PM

    This project is not intended to be a general purpose replacement for the standard Go net package or goroutines. It's for building specialized services such as key value stores, L7 proxies, static websites, etc.

    You would not want to use this framework if you need to handle long-running requests (milliseconds or more). For example, a web api that needs to connect to a mongo database, authenticate, and respond; just use the Go net/http package instead.

    There are many popular event loop based applications in the wild such as Nginx, Haproxy, Redis, and Memcached. All of these are single-threaded and very fast and written in C.

    The reason I wrote this framework is so I can build certain network services that perform like the C apps above, but I also want to continue to work in Go.

  • by crawshaw on 11/4/17, 12:00 PM

    One of my favorite things about Go is that it cuts through the "threads vs. events" debate by offering thread-style programming with event-style scaling using what you might call green threads (compiler assisted cooperative multitasking that has the programming semantics of preemptive multitasking).

    That is, I can write simple blocking code, and my server still scales.

    Using event loop programming in Go would take away one of my favorite things about the language, so I won't be using this. However I do appreciate the work, as it makes an excellent bug report against the Go runtime. It gives us a standard to hold the standard library's net package to.

  • by olivierva on 11/4/17, 11:32 AM

    The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.

  • by fooyc on 11/4/17, 11:59 AM

    I love Go because I never had to write asynchronous, callback driven programs in this language. I hope it won't become the norm in Go, too.

  • by indescions_2017 on 11/4/17, 1:52 PM

    I'd be interested in the level seven reverse proxy application. As well as unix domain socket message queues. There are probably many other places in the networking pipeline evio could provide a boost.

    It's a testament to what is possible through the "syscall" and "golang/x/sys" facilities. As well as your confidence in playing with Linux internals ;)

  • by bsaul on 11/4/17, 12:32 PM

    Not sure i understand what the use case is. As soon as you start doing something on the event loop , you need some kind of way to perform the operation in another "thread" ( or goroutine or whatever). And then you start to need some kind of concurrency mechanism, and pay the price.

    Stripping those mechanism to pretend the event handling is faster only works if you never intend to have some real computation performed. That's never true in practice... Or am i missing something ?

  • by brian-armstrong on 11/4/17, 7:02 PM

    At this point, why not just use C++? I feel like people are trying to stretch Go way past what it's good for. It's not going to replace C++ where C++ is effective, and it shouldn't :)

  • by adrianratnapala on 11/4/17, 1:57 PM

    Worst of both worlds, only faster?

  • by cdoxsey on 11/4/17, 8:27 PM

    This is single-threaded? What are you going to do with the other 31 or 63 cores?

    The single-threaded nature of applications liked Redis an Haproxy is a singificant impediment to their vertical scalability. CPUs aren't getting faster, we're just going to get more cores, so anything that assumes there's only a single core seems like a dead end.

    Haproxy literally just added multithreading support in 1.8.