La concurrence de code est une valeur par défaut dans tout code Rails. Un serveur Web threadé servira simultanément de nombreuses requêtes HTTP, et chacune contiendra son instance de contrôleur. Les adaptateurs de travaux actifs filetés et les canaux de câble d’action gèrent également plusieurs demandes simultanément. Même lorsque l’espace de processus global est partagé, le travail pour chaque instance est géré séparément. Pour les scénarios où l’espace partagé n’est pas modifié, ce processus se déroulera sans problème.
Voyons en détail comment cela est géré dans nos applications Rails.
Exécuteur
Les exécuteurs séparent le framework et les codes d’application en enveloppant le code d’application.
L’encapsulation du code était plus complexe avant Rails 5.0. Pour protéger un code, soit des classes de middleware Rack distinctes ont été utilisées, soit un emballage direct a été utilisé. Avec les mises à jour récentes de Rails, l’exécuteur gère le wrapping en une seule étape qui est plus facile à comprendre.
Appelez l’exécuteur pour encapsuler le code de l’application lorsque vous l’invoquez.
Par exemple:
Une caractéristique intéressante de l’exécuteur testamentaire est sa réentrée.
Deux rappels de l’exécuteur sont ‘courir‘ et ‘compléter.’ Cela permet d’encapsuler le code en parties lorsqu’il n’est pas possible d’encapsuler le code sous forme de blocs.
Le thread actuel est déplacé vers le ‘running‘, bloquant temporairement le thread. Ainsi, le fil ne sera accessible par aucune autre requête qui essaie de le faire.
Rechargeur
Le Reloader fonctionne de manière similaire à l’Executor. Le code qui doit être protégé est encapsulé avant qu’une autre demande ne soit touchée. Ceci est utilisé dans les scénarios où le code d’application est appelé plusieurs fois par un processus de longue durée. Le plus souvent, dans Rails, les requêtes Web et les tâches actives sont par défaut encapsulées. Le Reloader est donc rarement utilisé.
Un Reloader est utilisé lorsqu’il est nécessaire de recharger l’application. Lorsque la condition demandée demande un rechargement, le Reloader retarde le rechargement de l’application jusqu’à ce qu’il soit sécurisé. Et pour les scénarios où les rechargements d’applications sont obligatoires, le Reloader attend que le bloc actuel soit exécuté et autorise le rechargement. Ainsi, le code est protégé des erreurs.
Les ‘to_run‘ et ‘to_complete‘ les rappels sont également utilisés par le Reloader.
Un déchargement de classe est impliqué dans le processus Reloader. Ici, toutes les classes chargées automatiquement sont supprimées et prêtes à être chargées davantage. Le rechargement de l’application ne doit avoir lieu qu’avant ou après le déchargement de la classe, et donc, les deux rappels supplémentaires de Reloader sont ‘before_class_unload‘ et ‘after_class_unload‘.
Executor et Reloaders sont également utilisés par les composants du framework Rails. ActionDispatch::Executor and ActionDispatch::Reloader sont inclus dans la pile d’applications par défaut. Chaque fois qu’il y a un changement de code, le Reloader sert une nouvelle copie de l’application pour une requête HTTP. La fonction Active Job utilise également Reloaders, tandis qu’Action Cable utilise Executor. Action Cable utilise également le before_class_unload de Reloader pour déconnecter toutes les connexions.
Comme nous l’avons vu, la concurrence de code est gérée par défaut avec les tâches actives en thread et les fonctionnalités de câbles d’action des codes Rails. Avec les récentes mises à jour de Rails, des exécuteurs et des rechargeurs sont également ajoutés pour améliorer la gestion de la concurrence du code.