5 ms·

EventMachine: scalable non-blocking i/o in ruby

82 points by tmm1 17y ago

macournoyer_ 17y ago
Great presentation! Some exciting new stuff in Eventmachine.
filterfish 17y ago
Excellent preso. If you are interested in eventmachine or just getting into it read this.
davidw 17y ago
This is what's frustrating about being a Tcl fan: Tcl had this something like 15 years ago, because it was necessary for Tk. "Tcl don't get no respect" :-/ That said, though, what separates the "men from the Erlangs" is that in Tcl, Ruby, Python, Javascript, and company, "never block the reactor" is the name of the game, you can't do a while { 1 } { something } in your event handler or it will wedge the whole thing. In Erlang, thanks to its built in scheduler, you can.
- tptacek 17y ago
  Look more closely at Ruby. It's Japanese [incr tcl].
  - davidw 17y ago
    Ruby's OO is nicer than Tcl's in some ways. Incr Tcl is sort of an ugly attempt to make Tcl look a bit like C++. Indeed, the Tcl core team came up with their own OO thing recently, that actually looks a bit more like Tcl: http://wiki.tcl.tk/18152 http://wiki.tcl.tk/18152
- viraptor 17y ago
  What always bugged me about Twisted, or similar design is that you have to really flex your brain to get proper error handling (or maybe I'm just not experienced enough with them? :) please correct me if I'm wrong) It seems that you need a lot of shared state to kill some other process that is connected to your action in some way... You need to set a flag that will stop the other code path in some place. Then you need to know how to resolve the conflict (is one process providing resources for the other one? how do you synchronise closing down?) In Erlang (or a similar multiprocess / actor-based system) you just kill the computation you want to stop. It's up to the killed side (or their supervisor) to know how to handle it - but it doesn't happen during the next computation loop, or when it's convenient - it handles the condition now.
  - deleted 17y ago
    [deleted]
- rubyrescue 17y ago
  should it be "the Erlangs from the eventboys"?
- axod 17y ago
  Why is that a good thing? Essentially what you're saying is that Erlang allows you to make idiotic mistakes?
  - davidw 17y ago
    If the logic of your program is: On event, do some big, long calculation. Why should you need to write the code differently from that? It's nice that the language/environment handles things for you, rather than manually dividing things up into little chunks.
    - axod 17y ago
      If your program is: Show a calculator. Why should you need to write the code to do each individual part of the calculator? I disagree, dividing up the work yourself into chunks means you retain complete control of when your code executes. That actually decreases the complexity of your code, since you know when everything will execute.
  - jerf 17y ago
    No. Things that are not Erlang turn you into a human compiler, forced to manually chop your code into pieces for the pleasure of the computer. Erlang allows you to actually write things without doing the chopping up the scheduler should do. Event-based libraries are great hacks on top of weak languages/runtimes that allow those weak languages to hobble forward into the present, but they shouldn't be confused for the right approach in the future. I do hope they don't become trendy. Of course, look for them to become trendy, then for one or more of them to rediscover the pleasure of actually writing code in a straightforward manner, so they will provide you with a preprocessor that tries to do the chopping up for you, but still won't solve the problem of doing too much work in one timeslice. Then they'll rediscover that cooperative multitasking was abandoned years ago for good reason. You know, there's nothing new under the sun, but sometimes you just wonder... this much hype around cooperative multitasking? Seriously?
    - axod 17y ago
      I can't disagree with you enough. I don't want anything else to decide what order my code runs. I want it to run in the order I decide. Once you move away from the stupid "I want these 100 things to run at the same time", and realize that's impossible unless you have 100 CPUs, then you can start to move forwards and learn a better way. Event based / async programming is simple once you get used to it, it's hugely liberating, and _extremely_ efficient. It reduces code complexity, and means you _know_ what order your code will execute in. Something that I kinda like knowing.
- BrianHammond 17y ago
  I learned Tcl back in college (say 15 years ago) and have not used it since. However, while investigating things like EM and Twisted, I for some reason thought of Tcl. I (and others [1]) asked on the Tcl mailing list about creating a "C10K" server in Tcl but unfortunately Tcl does not have support for epoll, kqueue, etc. at this time. [1] http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3750934 http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/37509...
tptacek 17y ago
As luck would have it, I'm sitting here writing a fuzzer for a trading protocol in EventMachine as we speak. Ruby and async network programming go together like gin and vermouth. It's one of the reasons I'm so happy with Ruby's block/lambda support, and so irritated with Python's: many of the basic programming idioms for evented network code have direct support in the Ruby language. I've done a fair bit of Twisted Python programming in the past, and I find EventMachine to be far more intuitive and flexible. On the other hand, EventMachine will crash on me once in a blue moon, and it swallows exceptions, which is extremely frustrating. They're both great packages. The big problem that still needs solving for EventMachine is evented adapters for an ORM (any ORM). You've always been able to talk to MySQL over an evented socket, but that's clumsy compared to DataMapper. I am still totally not sold that Ruby threads are tenable, so a lot of the "advanced" stuff in EventMachine does nothing for me. It's great even without it.
- jrockway 17y ago
  I am still totally not sold that Ruby threads are tenable, so a lot of the "advanced" stuff in EventMachine does nothing for me. FWIW, threads based on an event backend are a solved problem in Perl. The Coro library is what EM is trying to be; they should really take a look. ("Oh but it's PERL!!!!" Yeah, and it actually works.)
  - tptacek 17y ago
    Maybe, but part of the value of async programming is never having to thread, so none of this really lights me up.
    - BrianHammond 17y ago
      Honest question: is there a purely event-driven I/O framework (no threads anywhere)? The one that a lot of people have gotten excited about recently is Node.js and that uses threads for file I/O (libeio).
      - tptacek 17y ago
aantix 17y ago
Take a look at Juggernaut. It's an event server based on EventMachine that provides nice integration with Rails. Streams events to the client via Flash.
donw 17y ago
I recently had a chance to play around with EventMachine, as I wanted to set up an event-based scheduler within my application. I was not impressed. If you try and mix 'EventMachine' and 'other threadsafe code', it seems to fall down pretty hard. In my case, it would run anything executed via next_tick, but would refuse to run any timers... unless I defined a periodic timer in the main event loop, after which timers started working... but only every time the periodic timer executed. I dug through the code to see if I could fix the problem, and gave up after trying to figure out why they seem to implement timers in two different ways, and it doesn't seem very threadsafe (next_tick is, but none of the timer code looks to be). EM also expects that your entire application will run inside the EventMachine loop; there's no way to ask EM for a Reactor that you can then hand events. If you're not running threaded code, then EM will probably work just fine; the Thin webserver looks to be a really nice Rack deployment option if you're on MRI. If you need to mix EM up with anything else running on the same VM, look elsewhere.

82 points by tmm1 17y ago

macournoyer_ 17y ago

Great presentation! Some exciting new stuff in Eventmachine.

filterfish 17y ago

Excellent preso. If you are interested in eventmachine or just getting into it read this.

davidw 17y ago

This is what's frustrating about being a Tcl fan: Tcl had this something like 15 years ago, because it was necessary for Tk. "Tcl don't get no respect" :-/ That said, though, what separates the "men from the Erlangs" is that in Tcl, Ruby, Python, Javascript, and company, "never block the reactor" is the name of the game, you can't do a while { 1 } { something } in your event handler or it will wedge the whole thing. In Erlang, thanks to its built in scheduler, you can.

tptacek 17y ago
Look more closely at Ruby. It's Japanese [incr tcl].
- davidw 17y ago
  Ruby's OO is nicer than Tcl's in some ways. Incr Tcl is sort of an ugly attempt to make Tcl look a bit like C++. Indeed, the Tcl core team came up with their own OO thing recently, that actually looks a bit more like Tcl: http://wiki.tcl.tk/18152 http://wiki.tcl.tk/18152
viraptor 17y ago
What always bugged me about Twisted, or similar design is that you have to really flex your brain to get proper error handling (or maybe I'm just not experienced enough with them? :) please correct me if I'm wrong) It seems that you need a lot of shared state to kill some other process that is connected to your action in some way... You need to set a flag that will stop the other code path in some place. Then you need to know how to resolve the conflict (is one process providing resources for the other one? how do you synchronise closing down?) In Erlang (or a similar multiprocess / actor-based system) you just kill the computation you want to stop. It's up to the killed side (or their supervisor) to know how to handle it - but it doesn't happen during the next computation loop, or when it's convenient - it handles the condition now.
- deleted 17y ago
  [deleted]
rubyrescue 17y ago
should it be "the Erlangs from the eventboys"?
axod 17y ago
Why is that a good thing? Essentially what you're saying is that Erlang allows you to make idiotic mistakes?
- davidw 17y ago
  If the logic of your program is: On event, do some big, long calculation. Why should you need to write the code differently from that? It's nice that the language/environment handles things for you, rather than manually dividing things up into little chunks.
  - axod 17y ago
    If your program is: Show a calculator. Why should you need to write the code to do each individual part of the calculator? I disagree, dividing up the work yourself into chunks means you retain complete control of when your code executes. That actually decreases the complexity of your code, since you know when everything will execute.
- jerf 17y ago
  No. Things that are not Erlang turn you into a human compiler, forced to manually chop your code into pieces for the pleasure of the computer. Erlang allows you to actually write things without doing the chopping up the scheduler should do. Event-based libraries are great hacks on top of weak languages/runtimes that allow those weak languages to hobble forward into the present, but they shouldn't be confused for the right approach in the future. I do hope they don't become trendy. Of course, look for them to become trendy, then for one or more of them to rediscover the pleasure of actually writing code in a straightforward manner, so they will provide you with a preprocessor that tries to do the chopping up for you, but still won't solve the problem of doing too much work in one timeslice. Then they'll rediscover that cooperative multitasking was abandoned years ago for good reason. You know, there's nothing new under the sun, but sometimes you just wonder... this much hype around cooperative multitasking? Seriously?
  - axod 17y ago
    I can't disagree with you enough. I don't want anything else to decide what order my code runs. I want it to run in the order I decide. Once you move away from the stupid "I want these 100 things to run at the same time", and realize that's impossible unless you have 100 CPUs, then you can start to move forwards and learn a better way. Event based / async programming is simple once you get used to it, it's hugely liberating, and _extremely_ efficient. It reduces code complexity, and means you _know_ what order your code will execute in. Something that I kinda like knowing.
BrianHammond 17y ago
I learned Tcl back in college (say 15 years ago) and have not used it since. However, while investigating things like EM and Twisted, I for some reason thought of Tcl. I (and others [1]) asked on the Tcl mailing list about creating a "C10K" server in Tcl but unfortunately Tcl does not have support for epoll, kqueue, etc. at this time. [1] http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3750934 http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/37509...

tptacek 17y ago

As luck would have it, I'm sitting here writing a fuzzer for a trading protocol in EventMachine as we speak. Ruby and async network programming go together like gin and vermouth. It's one of the reasons I'm so happy with Ruby's block/lambda support, and so irritated with Python's: many of the basic programming idioms for evented network code have direct support in the Ruby language. I've done a fair bit of Twisted Python programming in the past, and I find EventMachine to be far more intuitive and flexible. On the other hand, EventMachine will crash on me once in a blue moon, and it swallows exceptions, which is extremely frustrating. They're both great packages. The big problem that still needs solving for EventMachine is evented adapters for an ORM (any ORM). You've always been able to talk to MySQL over an evented socket, but that's clumsy compared to DataMapper. I am still totally not sold that Ruby threads are tenable, so a lot of the "advanced" stuff in EventMachine does nothing for me. It's great even without it.

jrockway 17y ago
I am still totally not sold that Ruby threads are tenable, so a lot of the "advanced" stuff in EventMachine does nothing for me. FWIW, threads based on an event backend are a solved problem in Perl. The Coro library is what EM is trying to be; they should really take a look. ("Oh but it's PERL!!!!" Yeah, and it actually works.)
- tptacek 17y ago
  Maybe, but part of the value of async programming is never having to thread, so none of this really lights me up.
  - BrianHammond 17y ago
    Honest question: is there a purely event-driven I/O framework (no threads anywhere)? The one that a lot of people have gotten excited about recently is Node.js and that uses threads for file I/O (libeio).
    - tptacek 17y ago

aantix 17y ago

Take a look at Juggernaut. It's an event server based on EventMachine that provides nice integration with Rails. Streams events to the client via Flash.

donw 17y ago

I recently had a chance to play around with EventMachine, as I wanted to set up an event-based scheduler within my application. I was not impressed. If you try and mix 'EventMachine' and 'other threadsafe code', it seems to fall down pretty hard. In my case, it would run anything executed via next_tick, but would refuse to run any timers... unless I defined a periodic timer in the main event loop, after which timers started working... but only every time the periodic timer executed. I dug through the code to see if I could fix the problem, and gave up after trying to figure out why they seem to implement timers in two different ways, and it doesn't seem very threadsafe (next_tick is, but none of the timer code looks to be). EM also expects that your entire application will run inside the EventMachine loop; there's no way to ask EM for a Reactor that you can then hand events. If you're not running threaded code, then EM will probably work just fine; the Thin webserver looks to be a really nice Rack deployment option if you're on MRI. If you need to mix EM up with anything else running on the same VM, look elsewhere.