Le 13/10/2010 09:32, Kevin Hinault a écrit : > Le 11 octobre 2010 23:57, Guillaume Rousse <[email protected]> a > écrit : >> Bonjour. >> >> >> C'est joli tout plein, mais voilà, l'agent est relativement parallélisé. >> Et comme on ne se refuse rien, il utilise à la fois du multi-thread >> (pour gérer son interface web, si nécessaire) et du multi-processus >> (pour lancer ses taches, s'il tourne sous forme de démon). Et ce genre >> de situations peut aboutir à deux problèmes: >> - une corruption du fichier, pour le cas d'écriture simultanée >> - un mauvais fonctionnement du mécanisme de surveillance automatique de >> la taille du fichier, avec apparement un intervenant qui efface un >> fichier, tandis qu'un autre garde le descripteur correspondant à >> l'ancien... (http://forge.fusioninventory.org/issues/406) > > D'habitude je lis les messages de la liste plutôt que d'y répondre car > ce que j'y vois est d'un niveau bien supérieur au moins mais pour une > fois j'ai l'impression de pouvoir répondre. Je suis peut être à côté > de la plaque (tu jugeras) mais pour gérer les accès concurrents > multi-thread, multi-processus, ne serait-il pas plus efficient de les > rediriger vers un processus type démon qui ne servirait qu'à ça ? Ca > demande de mettre une communication client/serveur mais dans ce cas, > seul le serveur aurait le loisir de logger les messages et comme il > serait assez simple, il serait aussi robuste aux plantages. Tu as parfaitement raison. Le seul problème, c'est que ca ne correspond à la contrainte 'bidouille temporaire, même si totalement inefficace, en attendant un vrai changement d'architecture'...
-- BOFH excuse #299: The data on your hard drive is out of balance.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Fusioninventory-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/fusioninventory-devel
