Sommet 4D 2016 : Laurent Esnault présente les travailleurs et l’interface utilisateur en mode préemptif.

Notre propre vice-président de l’ingénierie, Laurent Esnault, explique l’échange d’informations entre plusieurs processus ET entre les processus et les formes lors de sa session Break Out : Preemptive Multi-threading au 4D Summit 2016. Grâce au multithreading préemptif, vous pouvez avoir plus de processus parallèles, et ainsi ajouter de plus en plus d’utilisateurs, que ce soit pour des applications de bureau ou web.

Si vous avez manqué la session de Laurent au 4D Summit 2016, regardez cette vidéo de 15 minutes et profitez d’une formation personnelle par le maître du multithreading préemptif !

Prérequis

Pour profiter du multithreading préemptif, vous devrez utiliser :

• 64 bits uniquement
• le mode compilé
• uniquement la commande preemptive-ready
• Pas de variables interprocessus
• Pas d’interface utilisateur

Mais n’ayez pas peur ! Nous avons des solutions puissantes et faciles à mettre en œuvre que nous présenterons en détail à l’aide d’exemples illustratifs.

Comment partager des informations entre processus

Si vous n’avez pas de variables interprocessus en mode préemptif, comment partager des informations entre les processus? C’est pourquoi nous introduisons un nouveau concept : les « workers ». Mais qu’est-ce qu’un worker exactement ?

Heureux que vous demandiez ! Il s’agit d’une boîte de messages associée à un processus spécifiquement dédié à l’exécution de ses messages. En utilisant la commande CALL WORKER vous pouvez envoyer un message d’un processus à un autre (pour lui envoyer des informations, ou lui demander de faire quelque chose). La syntaxe de cette commande est assez similaire à celle de la commande New process par exemple, vous pouvez passer n’importe quel paramètre et/ou méthode de projet.

Utilisons une petite animation pour mieux comprendre son fonctionnement :

Dans cet exemple, nous voulons transmettre des informations du processus d’application au processus myWorker. Le processus d’application est en cours d’exécution et le processus myWorker est en pause.

• Dans le processus d’application, la commande CALL WORKER est appelée pour transmettre certains paramètres à myWorker, et nous voulons que myWorker exécute la méthode du projet myMethod.
• Il crée un message qui est posté de manière asynchrone dans une boîte de messages dédiée au processus myWorker. Le drapeau est levé, donc le worker se réveille automatiquement et récupère le message, récupère le contenu (les paramètres) et exécute maMéthode.
• Lorsque le processus myWorker a fini d’exécuter myMethod, il ne meurt pas. Il est simplement en pause, attendant l’exécution d’un autre message. C’est la principale différence avec la commande New process qui crée un processus, exécute une méthode avec quelques paramètres, puis meurt.

Alors, quand un worker meurt-il ? En principe, il meurt lorsque vous fermez l’application ou si vous appelez la commande KILL WORKER commande. Elle ne tue pas brutalement le processus, elle envoie simplement un message au worker lui demandant de se suicider.

Démonstration : Workers

Jetez un coup d’œil à l’exemple de base de données utilisé pour la démonstration avec les explications correspondantes dans le post de Vanessa sur les workers.

Comment accéder à l’interface utilisateur à partir de processus préemptifs ?

Plus tôt, nous avons dit que vous ne pouviez pas accéder à l’interface utilisateur à partir d’un processus préemptif. De toute évidence, nous devions fournir une solution à ce problème. D’où l’introduction de la commande CALL FORM est introduite. Cette commande est similaire à la commande CALL WORKER . Cette fois, cependant, il ne s’agit pas d’une boîte de message associée à un processus, mais d’une boîte de message associée à une fenêtre.

CALL FORM permet d’envoyer un message à une fenêtre pour demander au formulaire qui s’y trouve d’exécuter une méthode avec certains paramètres.

Utilisons à nouveau une petite animation pour démontrer le concept :

Dans cet exemple, à partir d’un processus (qui pourrait être préemptif) ou d’un worker, nous voulons faire quelque chose dans un formulaire en cours d’exécution dans le même processus ou dans un autre.

• Nous appelons la CALL FORM et passons le numéro de référence de la fenêtre(c’est-à-dire la valeur long int retournée par la commande Open form window ) dans le paramètre d’entrée, comme la méthode du projet que nous voulons exécuter(maMéthode) avec quelques paramètres.
• On crée un message qui est posté de manière asynchrone dans une boîte de message associée à la fenêtre.
• Le processus qui gère la fenêtre détecte automatiquement qu’il a un message. Il récupère le message et exécute la méthode myMethod et ses paramètres.
• Ensuite, le processus continue à gérer la fenêtre « comme d’habitude » (en traitant les événements tels que l’appui sur la touche, l’appui sur la souris, etc.)

Comme vous pouvez le constater, ceci est assez similaire à l’exemple précédent sur les workers.

Démonstration : messagerie entre formulaires

Consultez l’ exemple de base de données utilisé pour la démonstration et les explications correspondantes dans le billet de Vanessa sur la messagerie entre les formulaires.