4 ms·

The issue was solved with epoll back in 2004. All modern socket processing should be using async IO. This is just an example of how to hold the sockets open a

by edoo 8y ago

The issue was solved with epoll back in 2004. All modern socket processing should be using async IO. This is just an example of how to hold the sockets open and use it more like a TCP server. Ruby might be the good choice for this if you only know Ruby.

WJW 8y ago
Hey, author here! This thing came out one of the internal hackathons in our company and I decided to make a blog post about because it gives some interesting insights into Ruby internals. It's not meant for production and if you need something like this "for real", I would always advise Go, Elang/Elixir or Haskell as a solid base to build on. With MRI Ruby you'll still effectively be limited to one core due to the GIL, so if you need to do any compute intensive work for each socket instead of just sending a string you'll rapidly run into that barrier. As I state in the post, memory usage is not all that great either.
protomyth 8y ago
https://illumos.org/man/5/epoll https://illumos.org/man/5/epoll While a best effort has been made to mimic the Linux semantics, there are some semantics that are too peculiar or ill-conceived to merit accommodation. In particular, the Linux epoll facility will -- by design -- continue to generate events for closed file descriptors where/when the underlying file description remains open. For example, if one were to fork(2) and subsequently close an actively epoll'd file descriptor in the parent, any events generated in the child on the implicitly duplicated file descriptor will continue to be delivered to the parent -- despite the fact that the parent itself no longer has any notion of the file description! This epoll facility refuses to honor these semantics; closing the EPOLL_CTL_ADD'd file descriptor will always result in no further events being generated for that event description. Brian Cantrill on epoll https://youtu.be/l6XQUciI-Sc?t=3424 https://youtu.be/l6XQUciI-Sc?t=3424
masklinn 8y ago
> The issue was solved with epoll back in 2004. You mean kqueue, and that was in 2000. Epoll came later, and is bad.

by edoo 8y ago

WJW 8y ago

Hey, author here! This thing came out one of the internal hackathons in our company and I decided to make a blog post about because it gives some interesting insights into Ruby internals. It's not meant for production and if you need something like this "for real", I would always advise Go, Elang/Elixir or Haskell as a solid base to build on. With MRI Ruby you'll still effectively be limited to one core due to the GIL, so if you need to do any compute intensive work for each socket instead of just sending a string you'll rapidly run into that barrier. As I state in the post, memory usage is not all that great either.

protomyth 8y ago

https://illumos.org/man/5/epoll https://illumos.org/man/5/epoll While a best effort has been made to mimic the Linux semantics, there are some semantics that are too peculiar or ill-conceived to merit accommodation. In particular, the Linux epoll facility will -- by design -- continue to generate events for closed file descriptors where/when the underlying file description remains open. For example, if one were to fork(2) and subsequently close an actively epoll'd file descriptor in the parent, any events generated in the child on the implicitly duplicated file descriptor will continue to be delivered to the parent -- despite the fact that the parent itself no longer has any notion of the file description! This epoll facility refuses to honor these semantics; closing the EPOLL_CTL_ADD'd file descriptor will always result in no further events being generated for that event description. Brian Cantrill on epoll https://youtu.be/l6XQUciI-Sc?t=3424 https://youtu.be/l6XQUciI-Sc?t=3424

masklinn 8y ago

> The issue was solved with epoll back in 2004. You mean kqueue, and that was in 2000. Epoll came later, and is bad.