vampire-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vampire-devel] structure la plus adéquat


From: Maxime Biais
Subject: Re: [Vampire-devel] structure la plus adéquat
Date: Wed, 10 Sep 2003 08:02:11 +0200

Wed, 10 Sep 2003 01:04:46 +0200
Sébastien <address@hidden> wrote:

> Du point de vu Python, un dictionnaire semblait une bonne structure,
> mais, en fait, je ne sais pas comment faire de recherche si ce n'est que
> par itérations successives ce qui n'est pas top en raison du nombre
> d'infos que l'on cherche et le nombre potentiellement élevé de machines.

C'est vrai que pour chercher une valeur dans un dict c'est pas
top. Franchement je pense qu'une liste triée avec une recherche
dichotomique c'est largement suffisant.

> Donc ma solution finale la plus appropriéé que je vois, est d'avoir
> autant d'AVL que d'architectures différentes dans la liste FinalHost,
> AVL triés par la valeur d'uptime et donc finalement, en cas de problème
> de compilo, se résoudre à chercher itérativement dans l'AVL s'il celui
> que l'on trouve ne possède pas le bon. En fait je suppose que le
> compilateur est la donnée la moins contraignante.

(stp utilise load average plutôt que uptime qui veut pas dire grand chose)

là je comprend pas trop il n'y a pas donnée 'moins contraignante', elles
le sont toutes autant.

exemple :
machine A : Os=freebsd, archi=i386 , CC=gcc-3.2, load=0.4
machine B : Os=freebsd, archi=i386 , CC=gcc-3.2, load=0.2
machine C : Os=freebsd, archi=sparc, CC=gcc-3.2, load=12
machine D : Os=linux  , archi=i386 , CC=gcc-3.2, load=0.1
machine E : Os=linux  , archi=i386 , CC=gcc    , load=2

a) 1 tarball sur tout
Si dans la tarball il est precisé dans "testable_host" [1] que TOUTES les
machines doivent être testées alors votre ordonanceur devra lancer les
tests en même temps sur B, C, D et E

b) 2 tarballs sur tout
Deux tarballs (a.tgz et b.tgz) toutes les deux testables sur toutes les
machines on aura :
a.tgz sur A, C, D et E
b.tgz sur B, C, D et E

c) 3 tarballs sur "os=freebsd,archi=i386"
a.tgz sur A
b.tgz sur B
puis C.tgz sur A ou B suivant la première qui soit libre de test (je viens
de m'apercevoir qu'il faudrait rajouté un champ dans la structure
FinalHost qui dirait si il y a un test en ce moment en execution sur la
machine, ça implique une gestion des threads assez relou : on va pouvoir
apprendre a faire des mutex en python -ça doit ressemblé a du java :)- )

[1] testable_host = une string qui va permettre d'indiquer sur quelles
machines doit être testé la tarball, le format de la string n'est pas
encore définie, ça sera du genre : "os=freebsd,CC=gcc-3.2" ou bien "*"
pour tester sur toute les machines

-- 
Maxime Biais




reply via email to

[Prev in Thread] Current Thread [Next in Thread]