Programmation asynchrone en Ruby : tour d’horizon des techniques natives (Partie 2)

Dans un précédent article, nous avons posé les bases des concepts présents autour de la programmation asynchrone. Les notions sont nombreuses, complexes et variées. Abordons maintenant les possibilités qui s’offrent à un développeur Ruby.

La classe Thread (native)

C’est un grand classique en Ruby. Démonstration :

Résultat :

Il y a tout un tas de méthodes pour arrêter un thread depuis lui même, le tuer de l’extérieur, le mettre en pause, demander son état, etc.

La classe Fiber (native)

Les fibers proposent les mêmes fonctionnalités que les threads, à deux différences près :
– l’ordonnancement est laissé au développeur plutôt qu’à l’interpréteur Ruby : les fibers ne sont jamais préemptés, c’est à dire interrompus
– du point de vue du développeur, les fibers ne sont pas exécutés en parallèle mais de manière concurrente au processus principal (pour rappel, cela signifie qu’ils s’interrompent à tour de rôle pour se partager le temps d’exécution)

Ça a l’air moins chouette dit comme ça, mais Alex D explique que les fibers sont rarement utilisés pour développer en Ruby, il s’agit plutôt d’outils pour créer de l’abstraction, par exemple pour créer une méthode retournant les valeurs d’un tableau l’une après l’autre sur demande.

Malgré l’apparence simplicité des threads que je viens de donner en exemple, les threads cachent une monstrueuse complexité quand il faut les synchroniser ou éviter des comportements chaotiques. Nous verrons dans un prochain article les possibilités offertes par une gem nous préparant des modules asynchrones thread-safe.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.