11–20 of 67 posts
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 ;)
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.
Earlier quoted context omitted.
The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems). I would speculate the performance win is because there is no stack switching and less channels. I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state et…
Yeah, but that's with 1 maximum thread. The whole point of Go is to use green threading to your advantage.
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.
The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems). I would speculate the performance win is because there is no stack switching and less channels. I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state et…
I very much agree. In the past, I have had quite some fun developing a few streaming parsers using Node.js, which also uses an event loop. And while these parser worked relatively good and efficient, debugging them was not an easy task. In addition, understanding the code is also a though challenge, especially for people other than the original authors.
When I started using Go more and more, I really enjoyed the different I/O-model using goroutines and blocking function calls. It also has a few drawbacks but the mental model is a lot easier to reason about.
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 ;)
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.
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.
The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems). I would speculate the performance win is because there is no stack switching and less channels. I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state et…
This is improving, even in C++. This is what the core loop of a line-based echo server could look like in C++17 (and something very similar compiles today on my machine)
void echo_loop (tcp::socket socket) {
io::streambuf buffer;
std::string line;
std::error_code ec;
do {
ec = co_await async_read_line (socket, buffer, line);
if (ec)
break;
ec = co_await async_write (socket, line);
} while (!ec);
}Earlier quoted context omitted.
The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems). I would speculate the performance win is because there is no stack switching and less channels. I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state et…
> I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up. This is improving, even in C++. This is what the core loop of a line-based echo server could look like in C++17 (and something very similar compiles today o…
Earlier quoted context omitted.
> I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up. This is improving, even in C++. This is what the core loop of a line-based echo server could look like in C++17 (and something very similar compiles today o…
Wow. That looks really simple.
Echo specific code starts on line 167. Everything above will hopefully be provided by the standard library once both the Networking TS and Coroutine TS merge in to C++20.
One nice thing about lines 1 - 165 though, is that it demonstrates how easy it is to extend the native coroutine capabilities in C++ to support arbitrary async libraries, even if the author of those libraries didn't know anything about coroutines. All this happens without breaking the ability to call these coroutines from C. You can even use async C libraries that only provide a void* argument to your callback.
[0] https://gist.github.com/anonymous/d9a258136431a352516122d1c9...