Que fait le worker?

Une fois créé, je veux savoir ce qu’un worker fait : interface dialogue, “moulinette” en cours d’exécution, au chômage, autre…
Le statut renvoyé par INFORMATIONS PROCESS ne m’éclaire pas sur ce cas :

  • je démarre un worker, il ouvre une fenêtre et fait DIALOGUE, statut = “en attente d’événement”
  • DIALOGUE est refermé, le worker se tourne les pouces, statut = “en attente d’événement”
    Je peux faire TUER WORKER, mais si j’ai besoin d’un worker dans 5 minutes, le gars du magasin de workers va me dire que c’était ballot d’assassiner le précédent qui était en parfait état.
    Bon, c’est juste un exemple simple, je peux regarder s’il a une fenêtre, mais je peux vouloir aller plus loin. De façon générale, quelle démarche utilisez-vous pour organiser le boulot des workers ?

Pas très clair, mon questionnement. Pour qu’on en cerne mieux le sens : est-ce que Storage est le bon endroit pour maintenir ce que fait un worker, savoir s’il est disponible, etc ?

Personnellement, et jusqu’à plus ample informé, je n’utilise pas (encore) les workers. Il faudra que j’y trouve un usage.
J’ai en revanche une utilisation extensive de Storage. Je ne sais pas si l’un remplace l’autre, les objectifs sont en principe différents. Probablement le fait est que chacun a son intérêt et son usage propre, et possiblement complémentaire.

: Arnaud DE MONTARD

Storage est le bon endroit pour maintenir ce que fait un worker,
savoir s’il est disponible

Dans mon storage je mets plein de paramètres relatifs à la scrutation d’envoi de mails dont un qui donne l’état de la scrutation.

Tu disposes avec la R4 de la commande https://doc.4d.com/4Dv17R4/4D/17-R4/New-signal.301-4104310.en.htmlNew Signal> qui répond à ce besoin !

Mais pourquoi donc vouloir tuer un worker. Si tu as besoin que le process se termine après son traitement, inutile d’utiliser un worker…

Personnellement, et jusqu’à plus ample informé, je n’utilise pas
(encore) les workers. Il faudra que j’y trouve un usage.
De ce que j’en comprends, par rapport à un process “classique” :

  • plus rapide à lancer
  • peut s’exécuter en préemptif
  • dispose d’une queue de messages (il peut faire autre chose que sa méthode “lanceuse”)
  • on peut le flinguer :mrgreen:
    Tout ça me semble beaucoup plus “moderne”. Je suis en pleine réflexion pour remplacer les process par des workers.

J’ai en revanche une utilisation extensive de Storage.
Merci !

: Arnaud DE MONTARD

Personnellement, et jusqu’à plus ample informé, je n’utilise pas

(encore) les workers. Il faudra que j’y trouve un usage.
De ce que j’en comprends, par rapport à un process “classique” :

  • plus rapide à lancer
  • peut s’exécuter en préemptif
  • dispose d’une queue de messages (il peut faire autre chose que sa
    méthode “lanceuse”)
  • on peut le flinguer :mrgreen:

Hello,

Premièrement, un process “classique” peut aussi s’exécuter en préemptif. Ce n’est pas limité aux worker.

Deuxièmement, je ne pense pas que d’afficher un dialogue dans un Worker soit approprié.
Le but d’un worker c’est de pouvoir traiter une pile de messages en FIFO (First IN First OUT) et donc d’avoir un traitement synchrone d’évènement pouvant venir de différentes sources. Un bon exemple serait le traitement des balances d’un compte.

Si tu affiches un dialogue, c’est que tu attends une intervention de l’utilisateur et tu bloques donc tous les autres messages dans la file d’attente.

Pour en revenir à la question de base. Le statut “en attente d’événement” est normal pour un process qui affiche un dialogue, car il attend l’évènement de l’utilisateur. Aussi un worker qui ne travail pas est en attente d’un évènement pour recevoir un message.

Donc effectivement, pourquoi veux-tu tuer ce pauvre worker qui ne t’a rien fait? Laisse-le vivre et garder l’espoir d’avoir peut-être quelqu’un qui pense à lui et lui envoie un message.

C’est vraiment le but d’un worker, avoir un process qui est toujours en attente et qui peut exécuter une action très rapidement sans devoir créer un process specific pour une action et devoir le tuer ensuite. Tu peux aussi exécuter différentes méthodes dans un worker, tu n’es pas limité d’appeler toujours la même méthode. Si tu veux que ton process meure après un traitement alors un process “classique” est tout à fait approprié.

: Gabriel INZIRILLO

Deuxièmement, je ne pense pas que d’afficher un dialogue dans un
Worker soit approprié.

: Gabriel INZIRILLO

Si tu affiches un dialogue, c’est que tu attends une intervention de
l’utilisateur et tu bloques donc tous les autres messages dans la
file d’attente.
Non, non, non. Pensez à Dialog(*)

Juste une piqure de rappel: comme vous souhaitez laisser vivre indéfiniment vos workers pensez encore plus aux blocages des fiches ! pensez à libérer les enregistrements sinon, ils seront verrouillés pour longtemps… :roll:

Malheureusement, au lancement d’un worker 4D est en lecture écriture… :twisted:

Effectivement je n’ai pas penser à cela.

Je me suis toujours fait l’idée qu’un worker ne devrait pas ouvrir de dialogue. Est-ce que je me trompe? Je n’ouvre presque jamais de dialogue avec (*) excepter si c’est pour ouvrir une palette flottante.

: Vincent DE LACHAUX

Non, non, non. Pensez à Dialog(*)

Ça veut dire que le dialogue créé via DIALOGUE(…;*) dans le contexte d’un worker perdure tant qu’on ne le ferme pas ou que le worker soit tué ?
Le worker pourra aussi recevoir et exécuter d’autres messages à posteriori ?
Quel est l’intérêt de créer un dialogue dans le contexte d’un worker ?

Un des avantages que j’y vois c’est de permettre d’avoir plusieurs dialogue ouvert dans le même contexte (même process) et donc ainsi faire l’économie d’un process par dialogue !

: Maurice INZIRILLO

Un des avantages que j’y vois c’est de permettre d’avoir plusieurs
dialogue ouvert dans le même contexte (même process) et donc ainsi
faire l’économie d’un process par dialogue !
Un process classique sait aussi faire DIALOGUE(…;*).
De toute façon, s’il y a de l’interface, c’est du coopératif donc, à priori, il n’y a pas de gain en terme de performance.

Une règle d’or dans mes base pré ORDA, c’est que la première ligne d’un nouveau process doit toujours être READ ONLY(*)

Ensuite tu passes en read write seulement quand cela est nécessaire et tu n’oublies pas de remettre en read only derrière.

Pour libérer un enregistrement, j’utilise UNLOAD RECORD plutôt que de tuer mon process, c’est plus élégant et nous force à savoir ce que fait notre code. Pour moi tuer un process pour libérer les enregistrement c’est comme de dire : “Je ne sais plus où j’en suis dans mes enregistrements bloqué… bon ben je tue le process sa fera un clean-up”

Dans mon on startup, j’initialise mes worker avec une méthode qui contient juste deux lignes :
<code 4D>
CALL WORKER(“my_worker”;“init_worker”)
</code 4D>

init_worker contient :
<code 4D>
READ ONLY(*)
ON ERR CALL(“my_main_error_handler”)
</code 4D>

Ensuite dans le on exit, je tue mes worker en laissant la stack de messages se finir.

<code 4D>
CALL WORKER(“my_worker”;“kill_method”)
</code 4D>

kill_method contient :
<code 4D>
KILL WORKER
</code 4D>

Cela dépend si l’on veut laisser finir l’exécution de la stack de message.

Je pense que l’utilisation d’un worker ou d’un process classique mérite que l’on passe du temps à savoir ce que l’on veut faire et s’il faut choisir l’un plutôt que l’autre. La décision est très importante à mon avis.

Tu disposes avec la R4 de la commande
https://doc.4d.com/4Dv17R4/4D/17-R4/New-signal.301-4104310.en.htmlNe
Signal> qui répond à ce besoin !
J’osais pas, jamais pigé si on peut parler des ß ou pas.
Si tu as besoin que le process se termine après son traitement,
inutile d’utiliser un worker…
Je ne pige pas trop : en supposant que je remplace un existant Nouveau process(faisTonTafPuisMeurs) par un APPELER WORKER(faisTonTaf)+TUER WORKER, et en dehors du fait qu’il est préférable de recycler un worker inoccupé, je bénéficie quand même d’une architecture plus “moderne”, non ?

Rohh lala Arnaud a violé la N.D.A… :lol:

Personne n’a dit qu’on n’avait pas le droit de TUER un worker ; la preuve il y a une commande pour cela. Simplement il ne faut pas le faire à tout bout de champ.

Dans mon cas, j’ai un process par dialogue (en simplifiant), mais j’utilise un worker en plus de mon process pour les calculs longs ; mais, je tue le worker en sortie de mon dialogue car je considère que le worker est associé à mon dialogue d’une certaine manière.

D’autres garderont ce worker, ou le partageront, etc…

: Manuel PIQUET

Personne n’a dit qu’on n’avait pas le droit de TUER un worker ; la
preuve il y a une commande pour cela. Simplement il ne faut pas le
faire à tout bout de champ.

Dans mon cas, j’ai un process par dialogue (en simplifiant), mais
j’utilise un worker en plus de mon process pour les calculs longs ;
mais, je tue le worker en sortie de mon dialogue car je considère que
le worker est associé à mon dialogue d’une certaine manière.

D’autres garderont ce worker, ou le partageront, etc…Personne n’a
dit qu’on n’avait pas le droit de TUER un worker ; la preuve il y a
une commande pour cela. Simplement il ne faut pas le faire à tout
bout de champ.

Dans ton cas de tuer le worker a un sens car tu veux qu’il vive le temps de faire tes traitements long liés à ton dialog.

Mais ce que veux faire Arnaud, tuer un worker après une simple execution d’une méthode n’a pas de sens car c’est déjà le comportement d’un process normal. Un worker est la pour traiter une pile de message, si tu traite un message et tu le tue autant utiliser un process normal. Le worker n’apportera rien de plus.

Après si le worker est créé, tué, recréé, retué, recréé, etc. plusieurs fois dans un cour laps de temps, je pense qu’il serait préférable de le garder vivant, cela pourrais s’apparenter à de la torture je ne suis pas sur que la ligue de défense des workers apprécie.

: Arnaud DE MONTARD

Tu disposes avec la R4 de la commande

https://doc.4d.com/4Dv17R4/4D/17-R4/New-signal.301-4104310.en.htmlN

Signal> qui répond à ce besoin !
J’osais pas, jamais pigé si on peut parler des ß ou pas.

Etant donné que l’on en parle dans le Blog 4D ce n’est plus confidentiel !

: Arnaud DE MONTARD

Si tu as besoin que le process se termine après son traitement,

inutile d’utiliser un worker…
Je ne pige pas trop : en supposant que je remplace un existant
Nouveau process(faisTonTafPuisMeurs) par un APPELER
WORKER(faisTonTaf)+TUER WORKER, et en dehors du fait qu’il est
préférable de recycler un worker inoccupé, je bénéficie quand même
d’une architecture plus “moderne”, non ?

Là j’en reste aux principes détaillés dans la doc. A ce jour je n’ai jamais entendu un 4D men évoqué le fait que new proces serait old school et que worker soit la voie royale à utiliser…

: Arnaud DE MONTARD

Je ne pige pas trop : en supposant que je remplace un existant
Nouveau process(faisTonTafPuisMeurs) par un APPELER
WORKER(faisTonTaf)+TUER WORKER, et en dehors du fait qu’il est
préférable de recycler un worker inoccupé, je bénéficie quand même
d’une architecture plus “moderne”, non ?
Ça me parait plus complexe de faire ça avec un worker. Il faut qu’un process se charge de tuer le worker quand le taf est terminé alors que le process fait le taf et se termine tout seul.

En quoi ce serait plus moderne ? C’est du code qui s’exécute dans tous les cas.

: Stanislas CARON

Il faut qu’un process se charge de tuer le worker
Pas besoin, https://doc.4d.com/4Dv17R3/4D/17-R3/TUER-WORKER.301-3907148.fr.htmlTUER WORKER> sans paramètre équivaut au suicide.
En quoi ce serait plus moderne ?
Bin justement, j’en sais fichtre rien ; la mode étant au grand débat, j’ai lancé le mien.

Entre process et worker, le second a une file d’attente de messages (fifo). Je me souviens qu’ITK avait une série de commandes “IPC” (inter process message) et plus d’une fois j’ai râlé de ne pas avoir ça dans 4D.