Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It looks like you can even build event chans yourself on linux, using syscall.Epoll* in a monitor goroutine and TCPConn.File().Fd() to get your connections' fds to pass in. (There are other calls on darwin, etc.) See https://gcmurphy.wordpress.com/2012/11/30/using-epoll-in-go/ and https://groups.google.com/forum/#!topic/golang-nuts/a6yfYIi5... for more.

The fsnotify lib at https://github.com/fsnotify/fsnotify has a similar challenge at a high level (ferry events from various syscalls into a Go chan) and may be interesting as a reference.

But: perspective. If KBs per idle conn are eating a well-provisioned modern server box whole, then back of envelope you might be at, like, hundreds of thousands to a million conns for a single box (few KB/conn * 1M = few GB), and, like, huge congrats for getting that far! Not the absolute limit of the hardware, maybe, but clearly not a toy!

Other folks also note that once you're juggling that many connections there are other things that could become big factors in scalability, like whether your kernel and network will remain happy, can you keep up if more conns than expected suddenly become active, and (I'd add) will the rest of your code (the stuff besides reads/writes) be able to keep up.

Still, if anyone wants to wrap the epoll-results-to-a-chan thing in a package, they can always post something + see if anyone uses it to do cool stuff. As you suggested, it's plausible there are places it can make code cleaner.



Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: