Programmation asynchrone en Ruby 3 : les Guilds (Partie 5)

Nous avons fait un tour plutôt large des diverses solutions pour réaliser un programme asynchrone en Ruby. Je vous propose de terminer cette série d’articles par une ouverture sur ce que pourrait apporter la prochaine version majeure de Ruby.

C’est en tombant sur cet article d’Olivier Lacan que j’ai entendu parler de la révision du modèle concurrentiel de Ruby.

Comme évoqué dans la partie 2, l’interpréteur Ruby souffre d’une limitation dans sa gestion des threads : ces derniers ne peuvent pas être exécutés simultanément en parallèle mais le sont chacun à leur tour. Ce mécanisme a été introduit pour offrir l’API des mutex aux développeurs et ainsi permettre de synchroniser les threads. Cette limitation a un impact important sur la performance de nos applications multi-processus.

Koichi Sasada est un développeur core de CRuby, l’interpréteur Ruby « officiel ». Il a proposé un nouveau modèle mêlant Threads et Fibers.

Voici une traduction de l’article d’Olivier cité plus haut, avec mes ajouts personnels entre crochets :
« Les Guilds sont composées d’au moins un Thread, qui à son tour a au moins une Fiber. Les Threads de différentes Guilds peuvent s’exécuter en parallèle, tandis que les Threads dans la même guilde ne peuvent pas [ils le sont à tour de rôle]. Les objets d’une Guild ne peuvent ni lire ni écrire sur les objets d’une autre Guild. »

ruby_3_guilds_threads_and_fibers

« Les Threads appartenant à la même Guild ne peuvent pas s’exécuter en parallèle car il existe un GGL (Giant Guild Lock). Cependant, les Threads de différentes Guilds peuvent s’exécuter en parallèle.

Vous pouvez penser un programme Ruby 2.x comme ayant une Guild unique. »

ruby_3_guilds_concurrency

« Un objet d’une Guild ne sera pas capable de lire ou d’écrire sur un objet mutable d’une Guild différente. Empêcher la modification [d’objets] permet aux Guilds de fonctionner en parallèle sans courir le risque d’accéder et de modifier les mêmes objets. »

ruby_3_guilds_object_access_restrictions

En revanche il sera possible de réaliser des « deep copy » d’objets d’une Guild à l’autre.

ruby_3_guilds_channels_object_copy

Il existera une méthode .freeze pour rendre immuable (constant) tout objet mutable :

Je vous invite à lire cette synthèse de Maciej Mensfeld qui récapitule ce que sont les Guilds.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.