Timers & modification de variable globale

Question

Bonjour,

Voilà une question plus sérieuse ;) en ce qui concerne les variables et leur mise à jour dans des fonctions (pouvant être fort complexe).

Imaginer que vous avez une varialbe %x qui a la valeur 10 à moment et vous créez un premier timer par exemple, 
/timer 1 10 code1 

et code1
alias code1 {
  ici il y a du code script qui prends 3s pour s'exécuter
  set %x 1
}

Un second timer est également exécuté
/timer 1 10 code2 

alias code2  echo -a x= %x

Si par hasard le second timer s'exécute 1s après (<3s), je voudrais savoir que m'affichera l'echo du code (1 ou 10) ????
Donc je voudrais savoir si l'ordonnencement de l'exécution est respectée avec l'utilisation des timers c à d que code2 du premier timer ne pourra s'exécuté qu'une fois code1 sera exécuté complètement (ds ce cas c la valeur 1 qui doit s'afficher). Ou bien si les codes sont exécuté en parallèles (code2 est exécuté alors que code1 n'a pas fini de tourner donc %x n'est pas encore mis-jour et vaudra 10) !!!

C très important pour moi de le savoir (j'espère que ce sera le 1 d'afficher sinon c très embêtant car si vous mettez ces deux timers respectivement dans deux events et si ces events se produisent avec un (très) faible décallage temporel et que le code1 est très long à s'exécuter, c très embêtant).

Merci de bien vouloir me répondre,
@++

cs_PaDa · Answer

ca t'affichera 10 car au moment de l'appel a code2 ton %x vaudra 1, code1 n'étant pas fini d'exécuter .
Il n'y a pas "d'ordonnancement" le code s'exécute quand tu lui demandes il fait son boulot.
Par contre voici ma vision , plus large peut être :
1) un alias qui s'éxécute en 3 secs c'est soit un alias très spécifique soit souvent un truc mal foutu :/
2) tu dis avoir mis tes deux timers dans des events : ceci est une très mauvaise chose , tu ne sais jamais de combien un server va ramer et si il te répondra a temps pour la suite de ton script dans le cas des raws , et les events bon c'est assez moyen aussi ! La bonne solution c'est soit de considérer que deux raws sont envoyés en même temps/dans l'ordre (je pense aux /whois la ya pas de souci tu fais les affichages directs ca marche bien)
Soit de se servir de la fin du code1 , pour mettre code2 ! (ou d'un raw /end of blabla)
ex:
/timer 1 10 code1 
alias code1 {
ici il y a du code script qui prends 3s pour s'exécuter
set %x 1
code2
}
et éviter en plus un timer pour code2...
bien sur c'est que mon avis mais les timer sauf refresh de dialog ou jeux , a éviter ...

PaDa

cs_PaDa · Answer

(sauf si ton code1 fait freezer mirc ce qui est MAL)
PaDa

Nymouas · Answer

Bonsoir PaDa,

Merci pour ta réponse, mais j'ai fait le test, en utilisant comme code pour faire qq sec une boucle while très très longue (de 1 à 100000) - ça fait freezer le mirc

Je t'explique mon "vrai" problème car ceci était dans le but de savoir s'il y avait ou non un ordonancement. Pour rappel, je fais un "petit" script (XDCCMonitoring) qui permet de mettre automatiquement des packs en queue (sur des bots principalement de type iroffer ou qui ressemble bcp - voir des bots sysreset également). Pour cela je me sers d'une queue que j'ai appelé virtuelle (en local) pour le bot considéré. Je me suis fixé certaines contraintes par exemple de ne pas hammerer le bot inutilement sauf dans une condition (et une seule) qd il n'y aucune queues libre pour les packs (et c un hammer de 300s par un timer) J'assigne à chacun de mes paquets de cette queue virtuelle un statut :
0) queuefull - statut par défaut du pack
1) inqueue - si le pack a été mis en queue sur le bot
2) insend - si le pack est en cours d'envoi
3) sendfailed - si le fichier reçu a échoué (pas complet)
4) success - si le pack a été reçu complètement

Afin de mettre à jour le statut d'un pack, je dois détecter certains event. Pour l'event inqueue, le bot m'envoie une notice de mise en queue qui me permet de changer le statut d'un pack de queuefull vers inqueue (si le bot dispose d'une queue - ce qui est généralement le cas). Par la même occasion, je demande le pack suivant de ma queue virtuelle (c à d un pack en queuefull) en lançant le trigger ctcp bot xdcc send #n°pack. Si le bot ne notifie plus rien, j'en reste là et je "pointe" ce pack comme courant ds ma liste virtuelle. Qd le bot m'envoie un fichier, l'event "dcc send" se produit (event ctcp), je modifie le statut du premier pack inqueue en un pack insend, je lui assigne son nom de fichier (inconnu jusqu'à ce moment) et ensuite, je fais un ctcp xdcc send du pack courant (premier pack en queuefull) ds ma liste. Lorsqu'un fichier est reçu avec succes (event filercvd), le nom du fichier me permet modifier le statut du bon fichier en send (si le bot a plusieurs sends, le premier fichier reçu n'est pas forcément le premier fichier envoyé)

Par contre, si le fichier n'est pas complet, je modifie son statut en sendfailed et c dans ce contexte là que vient se greffer ma question. Qd un sendfailed se produit, il est évident que je vais remettre en queue ce pack en première position queuefull de ma queue virtuelle. Si ce sendfaild est dû à un time out, il se peut que le bot m'envoie le fichier suivant qui était en queue et il demande le pack courant au bot (à cause de ce dcc send) AVANT que l'event getfail se produise effectivement mais que la notice de mise en queue sur le bot du fichier demandé par le dcc send arrive APRES l'event getfail. Dans ce cas, mon script se plantera car le pack sendfail remis en queue a été inséré à la place du pack qui a été demandé (bon ça doit pas ê très clair tout ça :P )

Afin de tenter de régler ce pb de délais qui peut survenir entre la notice d'un bot (souvent en retard) par rapport à l'event d'envoi de fichier par exemple, g placé des timers et de ce fait je me demandé si deux events ayant lieu quasi en même temps pouvait accéder à des variables en même temps (par exemple changer le statut d'un pack simulatément ce serait embêtant). Entre (), toute cette gestion des packs nécessite pas mal de boucle de test while pour mettre à jour les status mais qui peuvent prendre un certains temps au plus le nbre de packs dans la queue virtuelle est élevée et que le nombre de bots. Actuellement, ce script commence à bien fonctionner sauf dans certains cas un peu bizarre comme décrit précédemment.

Bon je termine là mon blabla, j'espère que tu as pu (un peu) comprendre ce que je fais comme script.

@++

PS : pour re-rappel, c mon premier script ... 
PPS : si tu veux, je peux te l'envoyer pour que les explications aillent avec le code et tu me diras si il y a moyen de faire mieux ou autrement ...

Timers & modification de variable globale

3 réponses

Votre réponse

Discussions similaires