attendre qu'un fichier soit modifier

Bonjour,

je souhaite créer une fonction nouvelles_donnees(const string&); qui attend que de nouvelle données soit écritent dans le fichier puis me les renvoie.
Mais pendant que la fonction attend, il ne faut pas que les ressources soit intensément utilisé, c'est à dire pas avec un violent while(true){...}

sauf que je n'est pas la moindre idée de la façon dont je pourrai faire ça :s

par hasard, il existe pas une lib toutes prêtes qui ferai ça ?? :mrgreen:

rmq: les données sont écrites par un autre programme, dont je pense pas que les mutex et autre sémaphore puissent m'aider.
par contre, s'il est possible de dire "je veux que tu lance `tel` fonction lorsque un programme externe à écrit dans `ce` fichier" ça me va aussi bien ;)


merci, mathieu

Il suffit de faire du pulling...

Par exemple, toutes les 5 secondes, tu ouvres le fichier et tu verifies ce qu'il y a dedant.

j'avais pas précisé, mais c'est justement ce que je cherche à éviter ^^

Il n'existe pas, à ma connaissance, d'indicateur pour te dire que le fichier a été modifié... D'une manière ou d'une autre, le pulling semble être inévitable.

Tu n'es peut-être pas obligé de vérifier tout le fichier. Peut-être que la dernière date de modification suffit :roll:

Si c'est la consommation CPU qui t'inquiète, tu peux très bien armer un timer qui exécute ta fonction de vérification toutes les x secondes... pendant ce temps, si c'est bien fait, tu ne consommes rien...

Je ne sais pas pour les unix, mais les windows permettent de mettre en place une notification quand un fichier est modifié. En .NET, je crois que ce serait la classe FileSystemWatcher, en Win32, des trucs genre FindFirstChangeNotification.

aïe, pas cool ça...

parce que je pensé faire qqch qui réagisse instantanément, je pourrai bien baisser la durée du timer, mais comme il risque d'y avoir beaucoup de processus en même temps, je suis pas sur que ça le fasse...

et par exemple, kdevellop, il préviens quand le fichier est supr ou modifier par une source externe, il fait du pulling?

edit:
@JolyLoic: thx, je vais chercher des infos la dessus, des fois que quelque part ils parlent d'un équivalent unix ^^

Citation:

---

parce que je pensé faire qqch qui réagisse instantanément, je pourrai bien baisser la durée du timer, mais comme il risque d'y avoir beaucoup de processus en même temps, je suis pas sur que ça le fasse...

---

Tu peux baisser le timer a 100ms par exemple... ça ne posera pas de pb je pense. Ne descent pas en dessous des 10ms par contre... tu risquerais d'avoir des surprises.

Citation:

---

et par exemple, kdevellop, il préviens quand le fichier est supr ou modifier par une source externe, il fait du pulling?

---

Je pense oui... Meme pour la fonction FindFirstChangeNotification je pense que ça marche comme ça en interne. Je me trompe peut-etre mais je ne vois pas comment ça pourait marcher autrement...

Edit : Si une âme eclairé saurai me confirmer ou nous en dire + :D

FindFirstChangeNotification(), ça m'étonnerait que ce soit du pulling (ce serait pas plutôt polling ?), puisque c'est directement géré par le kernel.

Une ChangeNotification est un objet de synchronisation du kernel, donc je pense que le kernel "signale" l'objet dès qu'il touche à un fichier que l'objet surveille.
Et comme tout objet de synchronisation, dès qu'il est "signalé", tout thread qui l'attend (avec WaitForSingleObject()) est réveillé "instantanément"...

C'est un peu magique tout ça :koi:

Ca marcherai donc un peu comme pour les conditions dans boost::thread::condition ?

Excuse moi si je parle en boost... :mouarf:

Code:

---

1 2 3 4 5 6

boost::condition cond; // une condition ... scoped_lock lock(mutex); cond.wait(lock); // attente de la condition ... cond.notify_one(); // notification

---

ça veux dire que toute action, aussi minime qu'elle soit, est notifiée ? que quelqu'un l'attende ou pas ? ça n'est pas un peu lourd ?

Je suis p'tetre trop curieux :aie:

Ben, le kernel est forcément au courant puisque c'est lui qui touche aux fichiers, et si un objet ChangeNotification existe, il regarde si l'objet en question n'est pas réglé pour surveiller ledit fichier...

FindFirstChangeNotification() crée l'objet.
FindNextChangeNotification() resette l'objet (il repasse de "signalé" à "non-signalé" pour qu'on puisse à nouveau l'attendre).
WaitForSingleObject() et ses soeurs permettent au thread appelant d'attendre que l'objet soit signalé.
Et toutes ces fonctions sont directement supportées par le Kernel de Windows et exportées par Kernel32.dll

Et je suis désolé pour les threads de boost, je ne les connais pas. Je ne sais même pas si l'implémentation Win32 de boost utilise les fonctions d'attente de Windows...

J'ai un peu de mal avec les fonctions de l'API... Mais c'est interessant ;)
Comment fait on pour assurer la portabilité si on est obligé de passer par ces fonctions ? :koi:
En tout cas, merci pour ces infos Medinoc, il va falloire que je creuse :hola:
Je meterai bien :resolu: mais ça n'est pas mon post à la base :mouarf:
Si tu as des questions sur boost un jour... n'hesite pas :lun:

ouai, on fait comment pour la portabilité? parce que je trouve pas grand chose pour unix :(

et sinon, pour en revenir au p[uo]lling, es ce que c'est jouable a votre avis si j'ai par exemple 300 processus qui font ça en même temps (sureveillant chacun un fichier)?

Perso, je préfèrerais un processus qui surveille 300 fichiers.

Pour l'existance d'une fonction de notification de ce genre sous unix, peut-être en contactant un forum spécialisé unix plutôt qu'un forum C++ ?

Pour comment faire du portable, bien c'est simple, tu définis toi même une interface indépendante du système (éventuellement en t'appuyant sur boost::thread ou boost::signal), et tu l'implémentes différemment pour chaque OS concerné. Puis tu la proposes à boost si tu en as le droit/l'envie... ;)

j'préfererai aussi un programme qui surveille 300 fichiers, mais en fait, mon programme c'est pour faire tourner en cgi sur un serveur apache, chaque utilisateur loggué sera connecté avec un processus du coup ;)

bon, j'vais demander sur le forum unix