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