EventMachine

11 avril 2012pierre couzy

Pourquoi• Idée initiale : se débarrasser des IO bloquantes• Les patterns les plus fréquents• Du cache• Des threads• De l’asynchrone• Le pattern Reactor

Le principe • Supprimer la dépendance 1-1 entre thread et IO. Approche

Thread-on-event

Qui ?• Node• Python• Java• C#• …

• Ruby

Comment ça marche ? • Les tâches bloquantes sont déléguées à l’OS• Ruby fournit à l’OS les moyens de rappeler votre code

• Deferrable • C’est la classe de base • Elle définit un pattern de callback

• callback : quand tout va bien• errback : le reste du temps

la Boucle d’EventMachine

• EM.run• EM.stop• EM.next_tick• EM.defer

http://timetobleed.com/eventmachine-scalable-non-blocking-io-in-ruby/

Les threads• next_tick renvoie sur le thread principal• defer renvoie sur le threadpool (20 par défaut)

EventMachine & callbacks• Deferrable force l’utilisation d’un callback

.. Dans lequel on va réutiliser le même pattern.. Qui va lui aussi imposer un callabck et un errback

… et ça va vite devenirtrès difficile

à relire.

Un peu de sucre ? • Empiler les callbacks, c’est laid.

• Solution : les fibres• Fiber : thread coopératif

• Le développeur maîtrise l’état • Le code rend la main explicitement (yield)

Exemple fibres

Et après ? EM::synchrony

http://www.youtube.com/watch?v=mPDs-xQhPb0

EventMachine• C’est super !• Code lisible avec EM::synchrony• Utilisation optimale des threads

• C’est nul !• C’est TRES fragile• Toutes les libs doivent suivre