Si je comprends bien, une contrainte au plus tôt consiste à dire « exécuter cette deuxième tâche dès qu'une première est terminée ». Ceci est le fonctionnement de base d'evQueue : un workflow est un enchaînement de tâches qui s'exécutent l'une après l'autre, dans l'ordre.
Sur cette capture d'écran, extraite de l'exemple d'un workflow qui fait l'équivalent de ls | wc -l, la deuxième tâche wc -l doit attendre que la première ls soit terminée avant de démarrer. Ça tombe bien car elle prend en entrée le résultat du ls.
Note qu'il est possible de mettre plusieurs tâches au même niveau (dans un même job) ; ces tâches s'exécuteront en parallèle, et quand toutes seront terminées, la ou les tâche(s) du job suivant pourra(ont) commencer à s'exécuter. C'est une implémentation du concept de barrière de synchronisation.
Pour revenir à la contrainte au plus tôt, il existe également une fonctionnalité avancée (evQueueWait) qui permet de formuler une condition très précise qu'une tâche devra attendre avant d'être lancée. Cependant, la combinaison de tâches à exécuter en parallèle et/ou de manière séquentielle suffit à répondre à la majeure partie des besoins.
Je ne vois pas trop ce qui pourrait coller à une exécution au plus tard dans evQueue. La date ou l'heure de fin d'un workflow n'étant pas connue à l'avance, on ne peut pas commencer « X temps avant ça ». Ai-je mal saisi la question ?
[^] # Re: Contraintes temporelles?
Posté par nicooo . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 3.
Bonjour devnewton,
Si je comprends bien, une contrainte au plus tôt consiste à dire « exécuter cette deuxième tâche dès qu'une première est terminée ». Ceci est le fonctionnement de base d'evQueue : un workflow est un enchaînement de tâches qui s'exécutent l'une après l'autre, dans l'ordre.
Sur cette capture d'écran, extraite de l'exemple d'un workflow qui fait l'équivalent de ls | wc -l, la deuxième tâche wc -l doit attendre que la première ls soit terminée avant de démarrer. Ça tombe bien car elle prend en entrée le résultat du ls.
Note qu'il est possible de mettre plusieurs tâches au même niveau (dans un même job) ; ces tâches s'exécuteront en parallèle, et quand toutes seront terminées, la ou les tâche(s) du job suivant pourra(ont) commencer à s'exécuter. C'est une implémentation du concept de barrière de synchronisation.
Pour revenir à la contrainte au plus tôt, il existe également une fonctionnalité avancée (evQueueWait) qui permet de formuler une condition très précise qu'une tâche devra attendre avant d'être lancée. Cependant, la combinaison de tâches à exécuter en parallèle et/ou de manière séquentielle suffit à répondre à la majeure partie des besoins.
Je ne vois pas trop ce qui pourrait coller à une exécution au plus tard dans evQueue. La date ou l'heure de fin d'un workflow n'étant pas connue à l'avance, on ne peut pas commencer « X temps avant ça ». Ai-je mal saisi la question ?
Nicolas - UFC-Que Choisir