Worker dollar

Par analogie avec les process locaux (Nouveau process avec un nom de process commençant par $), je n’ai ni trouvé https://doc.4d.com/4Dv17R3/4D/17-R3/APPELER-WORKER.301-3907149.fr.htmldans la doc>, ni essayé, ni ne me suis demandé si ça a du sens…
Que fait 4D si je lui demande APPELER WORKER("$monWorker";…) ?

Comme ca à froid, je dirai que c’est pas une bonne idée, d’autant plus qu’une fois fini, le process du worker ne fait plus rien et est en attente.
Donc, faire un “worker temporaire” ne me semble pas judicieux là.

Patrick

Patrick,

Mettre $ au début du nom du process ne signifie pas temporaire. Ça signifie qu’il est local, qu’il n’a pas d’alter ego sur le serveur, et donc pas d’accès aux données.

Effectivement, comme quoi, faire 2 choses en // c’est pas toujours éfficace :wink:
Mais sur le fond, cela reste pour moi inutile vu la manière dont les workers sont gérés

: Stanislas CARON

Ça signifie qu’il est local, qu’il n’a pas d’alter ego sur le
serveur, et donc pas d’accès aux données.
En fait, si, “$il” accède au données, à ceci près que l’alter ego dans ce cas est toujours le process principal, quel que soit “$il”. Conséquence, si “$il” devient “$ils” et que “$ils” ont la mauvaise idée de parler au serveur en même temps, ça va tout se mélanger dans le tuyau.

Donc :
a/ on respecte scrupuleusement la doc, “$il” ne peut pas parler au serveur
b/ si on a des comportements bizarres, on regarde si par hasard “$ils” ont bien lu a/

: Patrick EMANUEL

Comme ca à froid, je dirai que c’est pas une bonne idée, d’autant
plus qu’une fois fini, le process du worker ne fait plus rien et est
en attente.
Le fait que le worker ne meurt que si on le tue n’entre pas en ligne de compte, c’est valable pour n’importe quel worker : ça dépend de ce qu’on en fait.
Suppose que tu surveilles l’arrivée d’un fichier sur le disque, l’activité de l’utilisateur, s’il est l’heure d’assassiner le boss pour prendre sa place (*), ou tout ça à la fois : nul besoin du serveur.

(*) c’est juste un exemple, mais ça ouvre plus de perspectives sociales que tuer un worker pour prendre sa place.

Ca dépend si ton worker est payé en $.

: Arnaud DE MONTARD

En fait, si, “$il” accède au données, à ceci près que l’alter ego
dans ce cas est toujours le process principal
Ah ok, je n’avais jamais été plus loin que la phrase “Les process locaux ne doivent être utilisés que pour des opérations qui n’accèdent pas aux données”.
Mais bon, si on peut quand même mais que le comportement est aléatoire, je crois que j’ai bien fait et qu’il vaut mieux s’abstenir.

Quoi qu’il en soit, l’intérêt des process locaux est bien celui que tu décris.

Bonjour,

: Arnaud DE MONTARD

Par analogie avec les process locaux (Nouveau process avec un nom de
process commençant par $), je n’ai ni trouvé
<https://doc.4d.com/4Dv17R3/4D/17-R3/APPELER-WORKER.301-3907149.fr.htm

dans la doc>, ni essayé, ni ne me suis demandé si ça a du sens…
Que fait 4D si je lui demande APPELER WORKER("$monWorker";…) ?

Arnaud, je te prends la main dans le sac, ou plutôt la tête sur l’oreiller durant ma dernière conférence au summit ou durant le dernier WorldTour … :smiley:

Un Worker démarré sur le client n’a pas immédiatement de process répliqué sur le serveur. Lorsque le code du Worker déclenche des commandes comme STOCKER ENREGISTREMENT qui nécessite l’appel à la base de données, alors le process Worker est répliqué sur le serveur. Attention, CREER ENREGISTREMENT ne fait pas cela car la commande ne travaille que dans la mémoire du client …
Lorsque le Worker client ne tourne plus, ou ne fait plus appel aux données, alors le worker répliqué sur le serveur est libéré (disparait).

Donc en résumé, il est urgent de faire un distinguo entre les process et les workers et ne pas dire “il y a cela dans le process, on veux la même chose dans les workers”, car cela n’a pas de sens. En effet, il est important de considérer les deux notions (process et workers) comme des entités vaguement cousines au 4ème degré … et ne pas raisonner de manière similaire, car ce n’est pas la même chose. Cela sera exactement le même soucis entre les CHERCHER et le .query en ORDA … mais c’est un autre sujet.

Cordialement,

Merci Olivier, j’avais oublié ce détail… qui n’en est pas un !

Une autre subtilité m’échappe, en parlant de workers :
« 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 APPELER WORKER. »
Ce que voyant (on ne se refait pas), me suis précipité pour essayer APPELER FORMULAIRE(fenêtre du process principal) dans un contexte où le PP affiche une fenêtre. La méthode à exécuter comportait une simple demande de mise à jour de l’heure affichée. Curieusement, le PP répond mais c’est toujours Sur chargement qui est enclenché. Ça ne donnait pas l’impression que ça soit fait pour ça, quoi…

Bonjour,

Pourquoi faire cela ?
Premièrement le process principal ne doit pas afficher de fenêtre, car l’usage veut que l’on n’utilise pas le process principal.
Pour appeler le process principal, comme c’est un worker et qu’il porte toujours le numéro 1, il faut faire APPELER WORKER(1;“MethodeAExecuter”)

Cordialement,

: Olivier DESCHANELS

Pourquoi faire cela ?
Pour t’arracher brutalement à ton oreiller :lol:
Non, comme il m’arrive de tomber sur des bases où tout s’affiche encore dans le PP, c’était simplement de la curiosité, pour en arriver à la conclusion que ce worker là n’est pas tout à fait comme les autres quand il fait de l’interface. Je suis bien d’accord avec ta notion d’usage, mais la doc en est encore loin : Process principal : Le process principal gère les fenêtres d’affichage de l’interface utilisateur.

: Stanislas CARON

Ah ok, je n’avais jamais été plus loin que la phrase “Les process
locaux ne doivent être utilisés que pour des opérations qui
n’accèdent pas aux données”.
C’est décrit https://doc.4d.com/4Dv17R3/4D/17-R3/Introduction-aux-process.300-3906884.fr.htmldans cette page> (je ne joue pas le cador qui connait la doc par cœur, 1ère fois que je tombe là dessus)

Bonjour,

: Arnaud DE MONTARD

Je suis bien d’accord avec ta notion d’usage, mais la doc en est
encore loin : Process principal : Le process principal gère les
fenêtres d’affichage de l’interface utilisateur.
Oui, il s’agit des l’interfaces utilisateur autrefois appelée “utilisation directe”. Pas l’interface en menus créés.

Cordialement,

Ce que je veux dire est que, à ma connaissance, il y a encore un paquet de bases qui utilisent le PP en menus créés et que, toujours à ma connaissance, nulle part dans la doc on nous le déconseille. Le seul “encouragement” à ne pas utiliser le process principal est la préférence “masquer la fenêtre d’accueil” - assez mal nommée puisqu’en fait c’est le PP qui est masqué.