Discussion :

[morpheusmg]

Bonjour à tous!
Je crois que je n'ai jamais fait un titre si peu claire, mais là je ne trouvais pas dsl!

Voici ma question:
prenons un logiciel (ex vim). Avec celui-ci je lis un fichier. Si avec un autre logiciel, je modifie ce fichier, alors Vim me proposera de re-charger le fichier.

Mais justement, comment font les logiciels pour faire ça.
Je sais (enfin, je pense...)qu'ils regardent la date de modif du fichier, et si elle est différente que ce que pense Vim, alors c'est qu'un autre logiciel la utilisé, donc on propose de recharger la page.

Donc un algo serait le suivant:
1) j'ouvre le fichier f1
2) on crée un fichier temporaire ftempo dans lequel j'écris la date de modif du fichier f1
3)si la date de modif du fichier f1 (que je connais puisque je l'ai écrite dans ftempo) n'est pas celle que j'attend: un prog exterieur a modifier mon fichier
4) afficher un message s'il faut recharger le fichier

PROBLEME:
le problème de cet algo, c'est qu'il est exécuté une unique fois, donc on ne vérifie pas régulièrement si le fichier à été modifié par un autre programme

SOLUTIONS:
je ne vois que 2 solutions:
1)soit on mets un timer et toute les secondes, on lance notre notre algo ci-dessus=> on perds du temps et des ressources processeur juste pour vérifier une date

2)soit, il y a une interruption, et lorsque le fichier f1 est modifié alors un signal est envoyé au programme (ex Vim) et celui-ci propose de le recharger

3soit il y à une autre méthode mais je ne vois pas laquelle.

Selon vous, comment fait-on en C pour faire ce genre de chose?


En espérant avoir été clair dans mes explications

Par avance merci

[Obsidian]

Les trois, mon général.

Le problème du polling n'est pas nouveau. Sous Windows, les objets du noyau permettent nativement ce genre de choses. Sous Unix, il manque historiquement quelque chose pour faire ces traitements sur les fichiers, tant et si bien que chaque implémentation propose sa propre interface. Sous Linux, par exemple, c'est inotify qui est chargé de cela.

On remarque que la commande « tail -f » a le même problème et, en explorant les sources, on finit par se rendre compte qu'elle fait bien un contrôle toutes les secondes.

Enfin, dans le cas de VIM en particulier, tu peux te contenter de ne contrôler l'état du fichier qu'au moment où tu t'apprêtes, toi, à lire ou écrire dedans.

[morpheusmg]

A ok, d'accord!

En tout cas super, grâce à tes explications et aux mots clés, j'arrive à trouver de la doc pour m’informer!

Par contre j'ai encore une question. Je regardais un un peu "inotify" et d'après wikipédia (je ne dis pas que c'est une référence, je m'informe juste ), il y a des fonctions dans le header <sys/inotify.h>Ces fonctions servent à surveiller un fichier par exemple. Mais encore une fois, je retombe dans le problème, qu'il faut une boucle pour tester ce que renvoie les fonctions d'inotify.

En effet, à l'époque ou je faisait du microcontroleur à l'école, on pouvait déclarer des interruptions, permettant de quitter temporairement un code en train de s’exécuter.
Peux-t-on faire cela en C?

Un exemple serait un code qui compte: tatadidada 1,2,3... et hope, quand je tape un truc dans le terminal, alors mon code reçoit une interruption, et le traitement s’arrête.

Est-ce possible en C?
A oui, j'oubliais: je ne veux pas faire le code suivant (car ce n'est pas une interruption):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
for(i=1;;i++){
var++
if(buffer non vide){
break}
}

en tout cas merci obsidian!

[Obsidian]

Réponse courte : voir select().

Réponse détaillée :

En effet, à l'époque ou je faisait du microcontroleur à l'école, on pouvait déclarer des interruptions, permettant de quitter temporairement un code en train de s’exécuter. Peux-t-on faire cela en C? Un exemple serait un code qui compte: tatadidada 1,2,3... et hope, quand je tape un truc dans le terminal, alors mon code reçoit une interruption, et le traitement s’arrête.

Est-ce possible en C?

Oui et non. Ça existe, mais sous une forme légèrement différente de ce que tu imagines.

D'abord, il faut distinguer ce qui relève du C proprement dit, c'est-à-dire ce qui est établi dans la norme et que tout compilateur qui se respecte DEVRAIT reconnaître (et qui, donc, est portable), et ce qui relève de la programmation système, c'est-à-dire des fonctions proposées par ton système d'exploitation, fussent-elles ou non normalisées également.

Ensuite, il faut faire un peu de terminologie :

• Les « interruptions » sont généralement réservées aux IRQ, c'est-à-dire aux événements qui se produisent physiquement et au niveau du CPU, donc en dessous du logiciel (et a fortiori en dessous du système d'exploitation) ;
• Les interruptions logicielles ont été largement utilisées sous D.O.S. pour effectuer des appels systèmes et, par conséquent, beaucoup de personnes font l'amalgame. Mais ça reste un abus de langage ;
• Les signaux UNIX sont ce qu'il y a de plus proche de ce que tu cherches mais ils ne sont déclenchés que sur un nombre restreint d'événements et coûtent cher en ressources systèmes. Cependant, leur réception provoque l'appel automatique d'un « gestionnaire de signal » à l'initiative du système d'exploitation et qui prend la forme d'une fonction donnée dans ton programme ;
• Les fonctions de rappel (« callback ») sont des fonctions de ton programme dont tu passes l'adresse en appelant une fonction du système qui, elle, les rappelle lorsque c'est nécessaire ;
• Les exceptions, lorsqu'elles sont récupérables, sont également une manière de gérer cela. Mais, là encore, ça dépend du niveau où l'on travaille. Les exceptions du C++, par exemple, n'ont rien à voir avec celles du micro-processeur.

Tout cela pour dire qu'il y a beaucoup de choses similaires qui portent des noms différents en fonction du contexte de travail.

Maintenant, pour le problème — fort classique — qui t'intéresse. Il faut analyser la situation pour la solution se présente d'elle-même (ou, à tout le moins, que l'on sache où la chercher) :

— Tu veux pouvoir faire plusieurs choses à la fois : soit travailler sur plusieurs fichiers, soit faire autre chose s'il n'y a rien à faire sur le fichier en question ;
— Pour cela, les appels sur ledit fichier doivent être non-bloquants. Il est possible de passer un flag pour que ce soit le cas ;
— Le problème, ce que cela t'oblige à faire une attente active, donc à boucler sans arrêt jusqu'à ce qu'un fichier présente quelque chose d'intéressant ;
— Les attentes actives ne sont ennuyeuses que parce qu'on ne peut pas rendre la main au système en attendant ;
— Par conséquent, il nous faut obligatoirement un appel système qui nous permettent de spécifier ce que l'on veut faire. En l'espèce, il s'agit de surveiller plusieurs descripteurs de fichiers à la fois ;
— Cet appel existe : il s'appelle select() sous UNIX. Des variantes sont mêmes apparues avec le temps : pselect() et poll() (voire ppoll() sous Linux).

Maintenant, à quoi cela va-t-il servir ? En substance, il s'agit de surveiller plusieurs descripteurs à la fois et de se débloquer dès qu'il est établi que l'appel à l'un d'entre eux pour l'action spécifiée à l'avance (lecture, écriture…) sera non-bloquant.

Ça fonctionne notamment avec les sockets, et c'est nécessaire pour faire des logiciels serveurs multi-utilisateur. Classiquement, un serveur IRC, dont le cas de figure a été maintes fois débattu ici et qui sert d'exercice-type lorsque l'on s'entraîne à la programmation réseau.

Le problème, comme dit plus haut, c'est que ça ne fonctionne pas pour vérifier si le contenu d'un fichier a changé parce que, même dans le cas simple où l'on atteint la fin du fichier et où l'on attend qu'un processus tiers continue à le remplir, un appel en lecture ne bloquerait pas mais renverrait immédiatement EOF. À charge aux différents systèmes de proposer leur propre solution, donc, en attendant que la meilleure proposition soit standardisée dans la prochaine version d'une norme quelconque.

En ce qui concerne Linux, c'est inotify. Le principe était de faire une « extension » des fonctionnalités et, donc de proposer quelque chose qui soit compatible avec select() (entre autres choses). La fonction inotify_init() va donc initialiser un contexte et te renvoyer un descripteur de fichier, qui va se comporter comme un pipe. C'est par ce tube que le noyau va t'envoyer un message chaque fois qu'il va se passer quelque chose. Et tant que le noyau ne t'envoie rien, l'appel est bloquant par défaut (comportement ordinaire sous Unix).

Tu utilises ensuite la fonction inotify_add_watch() pour ajouter une surveillance sur un fichier avec une liste de points de contrôles considérablement accrues. La fonction va te renvoyer un « numéro de surveillance » (watch descriptor : wd) qui fonctionne sur le même principe que le numéro de fichier mais qui n'a de sens qu'au sein du contexte que tu as ouvert, et qui sert essentiellement à modifier ou supprimer cette entrée par la suite.

Enfin, tu utilises select() et tu surveilles ton contexte en même temps que tes fichiers et/ou tes sockets. Dès que le noyau aura quelque chose à te dire, l'appel sera automatiquement débloqué.

[morpheusmg]

wao! merci beaucoup!!! Ca semble tout de même très complexe, mais bigrement intéressant.
Je vais essayer de programmer un p'tit truc en suivant tes explications et conseils!
En tout cas merci beaucoup Obsidian

[Obsidian]

wao! merci beaucoup!!! Ca semble tout de même très complexe, mais bigrement intéressant.
Je vais essayer de programmer un p'tit truc en suivant tes explications et conseils!

Non, ce n'est pas très difficile, mais c'est un peu fouillis au départ, quand on n'en a pas l'habitude. Mais ça vient vite. Tu peux lire aussi ce fil, qui s'écarte un peu de ce que tu cherches à faire, mais qui reste instructif :

http://www.developpez.net/forums/d10...ert-lutiliser/

En tout cas merci beaucoup Obsidian

À ton service.