Bonjour.<br><br>J'ai été confronté au même problème, il n'y a pas si longtemps. Je l'ai résolu en attribuant des time-slots à mes scripts. C'est à dire que mes scripts ne pouvaient accéder au fichier de log que durant une période donnée (1s toutes les 1,5s).<br>
Pour ma défense, mes scripts prenaient entre 8 et 12 heures à l'exécution et je n'étais pas à 10 minutes près.<br><br><br><div class="gmail_quote">Le 13 octobre 2010 10:56, Guillaume Rousse <span dir="ltr"><<a href="mailto:Guillaume.Rousse@inria.fr" target="_blank">Guillaume.Rousse@inria.fr</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Le 13/10/2010 09:32, Kevin Hinault a écrit :<br>
<div>> Le 11 octobre 2010 23:57, Guillaume Rousse <<a href="mailto:Guillaume.Rousse@inria.fr" target="_blank">Guillaume.Rousse@inria.fr</a>> a écrit :<br>
>> Bonjour.<br>
>><br>
>><br>
</div><div>>> C'est joli tout plein, mais voilà, l'agent est relativement parallélisé.<br>
>> Et comme on ne se refuse rien, il utilise à la fois du multi-thread<br>
>> (pour gérer son interface web, si nécessaire) et du multi-processus<br>
>> (pour lancer ses taches, s'il tourne sous forme de démon). Et ce genre<br>
>> de situations peut aboutir à deux problèmes:<br>
>> - une corruption du fichier, pour le cas d'écriture simultanée<br>
>> - un mauvais fonctionnement du mécanisme de surveillance automatique de<br>
>> la taille du fichier, avec apparement un intervenant qui efface un<br>
>> fichier, tandis qu'un autre garde le descripteur correspondant à<br>
>> l'ancien... (<a href="http://forge.fusioninventory.org/issues/406" target="_blank">http://forge.fusioninventory.org/issues/406</a>)<br>
><br>
</div><div>> D'habitude je lis les messages de la liste plutôt que d'y répondre car<br>
> ce que j'y vois est d'un niveau bien supérieur au moins mais pour une<br>
> fois j'ai l'impression de pouvoir répondre. Je suis peut être à côté<br>
> de la plaque (tu jugeras) mais pour gérer les accès concurrents<br>
> multi-thread, multi-processus, ne serait-il pas plus efficient de les<br>
> rediriger vers un processus type démon qui ne servirait qu'à ça ? Ca<br>
> demande de mettre une communication client/serveur mais dans ce cas,<br>
> seul le serveur aurait le loisir de logger les messages et comme il<br>
> serait assez simple, il serait aussi robuste aux plantages.<br>
</div>Tu as parfaitement raison. Le seul problème, c'est que ca ne correspond<br>
à la contrainte 'bidouille temporaire, même si totalement inefficace, en<br>
attendant un vrai changement d'architecture'...<br>
<font color="#888888"><br>
--<br>
BOFH excuse #299:<br>
<br>
The data on your hard drive is out of balance.<br>
<br>
</font><br>_______________________________________________<br>
Perl mailing list<br>
<a href="mailto:Perl@mongueurs.net" target="_blank">Perl@mongueurs.net</a><br>
<a href="http://listes.mongueurs.net/mailman/listinfo/perl" target="_blank">http://listes.mongueurs.net/mailman/listinfo/perl</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>dimitry Ernot<br>membre du projet JNS<br><a href="http://jacknsee.sourceforge.net/" target="_blank">http://jacknsee.sourceforge.net/</a><br>membre du projet Ktopsy<br>
<div><a href="http://sourceforge.net/projects/ktopsy/" target="_blank">http://sourceforge.net/projects/ktopsy/</a></div><br>