Dans le temps les traitements lourds et chronophages devaient être gérés de telle sorte que les logiciels ne se bloquent pas complètement. Pour cela on devait disséminer la ligne
application.ProcessMessages;
un peu partout dans le traitement bloquant afin de l'empêcher de tout bloquer. Cela permettait à l'application de répondre aux sollicitations du système d'exploitation et de modifier l'affichage des composants que l'on aurait modifiés (par exemple une barre de progression, un compteur, une jauge, des graphiques, ...).
Les temps ont bien changé avec l'arrivée des processeurs multi threads puis multi coeurs.
Delphi et C++ Builder intègrent depuis pas mal de temps maintenant une classe TThread qui permet de sortir un traitement lourd du processus principal d'un programme.
Fort de son expérience dans ce domaine, Embarcadero a également mis en place des outils nous permettant de pousser les choses encore plus loin avec la parallélisation de traitements.
Sous Windows (depuis la version 95) qu'un programme se fige ne perturbait pas plus que ça le système d'exploitation. Cependant ceci n'est plus valable avec les applications mobiles qui doivent en permanence laisser l'utilisateur dans la capacité d'interagir avec elles et le système d'exploitation.
Une application figée c'est un message de l'OS proposant de la tuer et un utilisateur enclin à la mettre à la poubelle parce qu'il a l'impression qu'elle est plantée.
On doit désormais retenir et appliquer la règle suivante :
Les traitements synchrones bloquants sont à proscrire de tous les logiciels. Tout ce qui laisse supposer qu'un logiciel est bloqué doit être passé en asynchrone.
Sur le papier (ou à l'écran), cette règle est simple. A mettre en oeuvre elle ne l'est pas toujours car on tombe sur deux cas :
Dans le premier cas, il faut donc ruser. Dans le second juste lancer une tâche de fond et la laisser tourner jusqu'à ce qu'elle soit complète.
Le gros avantage avec les classes et fonctions proposées par Embarcadero c'est qu'elles font partie de la RTL. Elles sont donc accessible à la fois aux applications console, aux applications "serveur", aux applications utilisant la VCL et aux applications utilisant Firemonkey. Elles sont également compilables dans les différentes cibles gérées par l'environnement, qu'il s'agisse de Windows, de Mac OS X, de iOS, d'Android ou même de Linux (depuis la version 10.2 Tokyo Entreprise de Delphi).
A la gestion de processus s'ajoutent des objets permettant de traiter l'accès partagé aux mêmes ressources et la transmission d'informations.
Les classes à consulter lorsque l'on fait de la programmation poussée dans ce domaine sont les suivantes :
Du côté de la librairie de parallélisation :
Il y a d'autres classes, functions et procédures utilisées pour jouer avec les processus, je vous laisse vous reporter à la documentation pour avoir le détail.
Je reviendrai rapidement sur l'utilisation des processus dans des exemples de cas pratiques. Vous pouvez aussi consulter la liste de mes articles sur les processus.