A propos des workers

Les process workers constituent un moyen simple et puissant d'échanger des informations entre les process. Cette fonctionnalité est basée sur un système de messagerie asynchrone, permettant d'appeler spécifiquement des process ou des formulaires et de leur demander d'exécuter des méthodes avec des paramètres dans leur propre contexte.

Note : Une méthode projet peut également être exécutée avec des paramètres dans le contexte de tout formulaire à l'aide de la commande CALL FORM.

Un "worker" peut être "engagé" par tout process (via la commande CALL WORKER) afin d'exécuter des méthodes projet avec des paramètres dans le contexte du worker, ce qui permet d'accéder à des informations partagées.

Cette fonctionnalité répond aux besoins suivants en matière de communication interprocess dans 4D :

• Comme les workers peuvent être des process coopératifs ou préemptifs, ils représentent une solution idéale pour la communication interprocess entre les process préemptifs (les variables interprocess ne sont pas utilisables avec les process préemptifs).
• Ils fournissent également une alternative simple à l'emploi de sémaphores, qui peuvent s'avérer difficiles à mettre en oeuvre et à utiliser (cf. A propos des sémaphores).

Note : Bien qu'elles aient été conçues principalement pour les besoins liés à la communication interprocess dans le contexte des process préemptifs (accessibles en version 64 bits uniquement), les commandes CALL WORKER et CALL FORM sont disponibles dans les versions 32 bits et peuvent être utilisées avec des process en mode coopératif. 

Un worker est utilisé pour demander à un process d'exécuter des méthodes projet. Un worker est constitué des éléments suivants :

• un nom unique(*), également utilisé pour nommer son process associé 
• un process associé, qui peut exister ou non à un instant donné
• une boîte aux lettres
• une méthode de démarrage (optionnel)

(*) Attention, les noms des workers tiennent compte des majuscules/minuscules : "monWorker" et "MonWorker" peuvent exister simultanément.

Vous demandez à un worker d'exécuter une méthode projet en appelant la commande CALL WORKER. Le worker et sa boîte aux lettres sont créés à la première utilisation ; son process associé est également lancé automatiquement à la première utilisation. Si le process du worker est tué par la suite, la boîte aux lettres restera toutefois ouverte et tout nouveau message posté entraînera le lancement d'un nouveau process worker.

L'animation suivante illustre cette séquence :

A la différence d'un process créé par la commande New process, un process worker reste vivant après la fin de l'exécution de sa méthode process. Cela signifie que toutes les méthodes exécutées par le même worker le seront dans le même process, qui maintient son contexte (variables process, enregistrement courant, sélection courante...). Par conséquent, les méthodes exécutées successivement accèderont aux mêmes informations et donc les partageront, permettant ainsi aux process de communiquer entre eux. La boîte aux lettres du worker traite les appels successifs de façon asynchrone.

CALL WORKER encapsule le nom de la méthode ainsi que ses paramètres dans un message qui est envoyé dans la boîte aux lettres du worker. Le process du worker est alors démarré s'il n'existe pas déjà, et traite le contenu du message (il exécute la méthode avec ses éventuels paramètres). Cela signifie que CALL WORKER va généralement rendre la main avant que la méthode ait terminé son exécution (les traitements sont asynchrones). Pour cette raison, CALL WORKER ne retourne pas de valeur. Si vous avez besoin qu'un worker retourne des valeurs au process qui l'a appelé (callback), vous devez utiliser à nouveau CALL WORKER afin de repasser les informations attendues au process appelant. Bien entendu dans ce cas, l'appelant lui-même doit être un worker.

Il n'est pas possible d'utiliser CALL WORKER pour exécuter une méthode dans un process créé par la commande New process. Seul un process worker a une boîte aux lettres et donc, peut être appelé par CALL WORKER. Notez qu'un process créé par New process peut appeler un worker, mais ne peut pas être appelé en retour.

Les process workers peuvent être créés sur 4D Server via des procédures stockées : par exemple, vous pouvez utiliser la commande Execute on server pour exécuter une méthode qui appelle la commande CALL WORKER.

Un process worker est détruit par l'appel de la commande KILL WORKER, qui vide la boîte aux lettres du worker et demande au process associé de ne plus traiter de message, puis de terminer son exécution après la fin du traitement de sa tâche en cours.

La méthode de démarrage est la méthode utilisée pour créer initialement le worker (première utilisation). Si CALL WORKER est appelée avec un paramètre méthode vide, la méthode de démarrage du worker est automatiquement réutilisée comme méthode à exécuter.

Le process principal, créé par 4D à l'ouverture de la base pour l'interface utilisateur et le mode application est un process worker et peut être appelé par CALL WORKER. A noter que le nom du process principal peut varier en fonction de la langue de 4D, mais a toujours le numéro 1 ; par conséquent il est plus pratique de le désigner par son numéro de process au lieu de son nom lorsque vous utilisez CALL WORKER.

Tous les process workers, à l'exception du process principal, ont le type Process worker (5) retourné par la commande PROCESS PROPERTIES.

Des icônes spécifiques identifient les process workers dans l'Explorateur d'exécution et la fenêtre d'administration de 4D Server :

Type de process type	Icone
Process worker préemptif
Process worker coopératif

Le schéma suivant montre une séquence de communication type entre deux workers et un formulaire. Les informations échangées sont de simples chaînes de caractères :

1. Worker_1 appelle Worker_2 et passe "Hello!" en paramètre.
2. Worker_2 récupère et lit le message. Il rappelle Worker_1 et lui passe "Hello!" en paramètre.
3. Worker_2 appelle alors le formulaire MyForm et lui passe "I work" en paramètre. Il démarre une opération longue et son statut devient 'busy' (occupé).
4. Worker_1 appelle Worker_2 deux fois mais, grâce au système de messagerie asynchrone, les messages sont simplement placés dans une file d'attente. Ils sont ensuite traités une fois que Worker_2 est disponible - après que Worker_2 a appelé MyForm.