1. EventMachine
11 avril 2012
pierre couzy

2. 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

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

4. Qui ?
• Node
• Python
• Java
• C#
• …
• Ruby

5. 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

8. la Boucle d’EventMachine
• EM.run
• EM.stop
• EM.next_tick
• EM.defer
http://timetobleed.com/eventmachine-scalable-non-blocking-io-in-ruby/

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

10. 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 devenir
très difficile
à relire.

11. 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)

12. Exemple fibres

13. Et après ? EM::synchrony
http://www.youtube.com/watch?v=mPDs-xQhPb0

14. 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