3 // ça sera peut-être une struct s'il n'y a rien d'autre que les deux paramètres
7 unsigned int nbCores()const;
8 const std::string& name()const;
11 // ça sera peut-être une struct s'il n'y a rien d'autre que les deux paramètres
15 const std::string& name()const;
16 // float pour pouvoir gérer plus tard des containers qui peuvent être lancé
17 // à plusieurs sur le même coeur.
18 const float parallelism()const;
19 // normalement, pas besoin de start. Quand yacs lance un traitement, il
20 // commence par faire un "load" qui cherche le container avec les
21 // caractéristiques données et il lance un nouveau s'il ne le trouve pas.
22 // Donc on peut s'appuyer sur le mécanisme existant et jouer sur les
23 // caractéristiques pour identifier le container.
24 //virtual void start(const std::string& resourceName, unsigned int index);
27 // probablement une struct
29 // Cet objet est créé par le WorkloadManager chaque fois qu'une tâche peut être
30 // lancée et il contient l'identification du container à utiliser pour faire
31 // le traitement. voir Task.run
34 const Resource* resource()const;
35 const ContainerType* type()const;
36 // indice du container parmi ceux du même type sur la resource:
37 unsigned int index()const;
41 // Cet objet doit être créé par YACS et soumis au WorkloadManager
44 const ContainerType* type()const;
45 // Cette méthode est à implémenter dans YACS. Elle est appelée par le
46 // WorkloadManager au moment où une ressource est disponible et en paramétre
47 // on trouve l'identification du container à utiliser. YACS permet déjà
48 // d'identifier les containers par leur nom. A partir des informations de
49 // l'objet en paramètre on peut construire un nom de container qui sera unique.
50 // Avec ce nom, on peut utiliser les méthodes existantes pour charger le
51 // container salome / kernel et lancer le traitement à faire dans le noeud
53 // Les traitements à faire dans cette fonction sont: trouver le container
54 // kernel et si besoin l'initialiser, lancer le traitement du noeud et
55 // attendre la fin du calcul.
56 virtual void run(const Container& container)=0;
60 // Cet objet doit être créé par YACS à chaque exécution d'un schéma.
63 // Fonction à appeler par YACS avant le début de l'exécution du schéma pour
64 // renseigner les ressources disponibles. A mon avis, on peut se limiter dans
65 // un premier temps de prendre toutes les ressources du catalogue qui peuvent
66 // lancer des containers. Cela suffit pour le lancement sur cluster. En local
67 // on pourrait avoir envie de ne pas utiliser tous ce qu'il y a dans le
68 // catalogue, mais on n'a qu'à modifier le catalogue à la main si on veut
70 void addResource(Resource* r);
72 // Fonction à appeler par YACS au moment où un noeud de traitement est prêt à
73 // être lancé. Cet appel ajoute la tâche dans la queue d'attente et rend tout
74 // de suite la main. La fonction 'run' de la tâche sera appelée plus tard, au
75 // moment où une ressource est effectivement disponible.
76 void addTask(Task* t);
78 // Fonction à appeler par YACS pour démarrer le moteur qui distribue les tâches.
79 // Il y aura au moins deux fils d'exécution: un qui gère les arrivées dans la
80 // queue et un qui gère les fins de tâche. Ce sont ces deux fils qui démarrent
81 // ici. Après, chaque exécution de tâche aura son propre fil.
84 // Fonction à appeler par YACS pour indiquer qu'il n'y aura plus de tâches à
85 // soumettre. Le moteur pourra s'arrêter à la fin des tâches en cours.