J'ai toujours été perturbé par FAM. Avoir un démon pour une tâche de ce type...
Mais c'est fini !
Le projet Marmot qui a été chauffé à blanc par le démon de la Fam nous a accouché du Gamin.
C'est pas claire ? Voir ici :
http://www.gnome.org/~veillard/gamin/overview.html(...)
Journal Gamin
25
août
2004
# Sympa le lien...
Posté par Christophe Chailloleau-Leclerc . Évalué à 4.
Oui, je sais, il est tard, désolé M. Daniel Veillard pour ce mauvais jeu de mot sur votre nom...
--> []
*Aïe*
Oublié d'ouvrir la porte...
Fatigué moi...
Zou, au pieu !
[^] # Re: Sympa le lien...
Posté par 007 . Évalué à 2.
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: DNotify
Posté par 007 . Évalué à 4.
Tu parles de ça :
http://www.devchannel.org/devtoolschannel/04/05/13/2146252.shtml(...) (chercher dnotify dans la page)
Ça tombe bien, c'est ce que utilise Gamin (uniquement sous Linux).
> c'est ce qu'utilise ROX
Gamin est dans rawhide qui est sync Gnome 2.8.
Donc nautilus utilisera Dnotify sous Linux (via Gamin).
Avantage de Gamin, est d'être compatible Fam. Donc Gnome et KDE va utiliser Dnotify.
Fam n'est plus dans rawhide :-)
[^] # Re: DNotify
Posté par 007 . Évalué à 2.
Et Gamin. Espérons que KDE ne va pas encore gueuler car KDE va dépendre gamin qui dépend de glib-2.
[^] # Re: DNotify
Posté par Frédéric Péters (site web personnel) . Évalué à 4.
- ouverture des fichiers (ça complique le umount())
- impossible de surveiller une hiérarchie de répertoires (à noter que ce n'est pas dérangeant pour le cas du file manager qui n'affiche typiquement qu'un répertoire)
- grosse perte de perfs quand modifs fréquentes (ce que gamin contourne en passant au polling dans ces cas-là)
Ça a déjà souvent été discuté sur la liste linux-kernel et je pensais me souvenir qu'une solution avait été adoptée. Mais soit ce n'est pas le cas, soit je ne tombe pas dessus ce soir.
Pour référence, j'ai trouvé une tentative avortée (mais qui évoque les problèmes) http://www.kerneltraffic.org/kernel-traffic/kt20040625_264.html#1(...)
et une autre, http://lwn.net/Articles/98922/(...) qui ne l'est peut-être pas mais qui n'en est pas pour autant encore intégrée.
Pour la surveillance d'une hiérarchie, j'avais bricolé un outil (utilisant dnotify), encore dispo dans le CVS ici: http://cvs.labs.libre-entreprise.org/cgi-bin/cvsweb.cgi/monitordir/(...)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: DNotify
Posté par 007 . Évalué à 2.
Même problème pour une methode poll. Techniquement ça parait irréalisable. Le noyau bosse avec les inodes (ou vnode) mais pas avec les chemins. Y a aussi les cas subtile comme la cas du déplacement d'un répertoire qui sort de la "zone de surveillance". Ajoutes les "mount --bind" et autre goodies (lien physique entre répertoire) et c'est l'enfer.
> - grosse perte de perfs quand modifs fréquentes
Non :-)
C'est parce que ça marche très bien !
En mode poll (une fois par seconde par exemple), s'il y a 10 modifcations par secondes tu en rates 90 % !
[^] # Re: DNotify
Posté par Frédéric Péters (site web personnel) . Évalué à 1.
http://www.advogato.org/person/DV/diary.html?start=176(...)
:
It also enable both kernel (dnotify) and polling monitoring of resource. It serves 2 purpose at the moment, one is checking when monitored resources do not exist (dnotify forces to open() the file) the second one is to minimize the monitoring costs on bysy resources, in that case monitoring is switched to polling untill the resource comes back to a quiet status. An example of this is that watching an active directory (say you're running make in a source tree you're watching) should not eat all the CPU anymore due to the constant flow of kernel dnotify events, FAM events, and nautilus redisplay.
[^] # Re: DNotify
Posté par 007 . Évalué à 1.
Avec DNotify tu as plein d'évènements qui peuvent remontés rapidement. Si les performances étaient mauvaises, tu aurais moins d'évènement.
Moins performant => moins rapide (logique).
Par contre ce niveau de performance (traquer 40 modifications en 1 secondes par exemple) est totalement inutile pour nautilus qui passe son temps a prendre en compte les évènements DNotify.
Dans le cas, il faut calmer le jeu et désactive temporairement DNotify (Rien du tout, c'est forcément moins performant que quelque chose :-)).
Au final, pour nautilus, ça peut dégrader les performances de Nautilus (et pas de DNotify) d'avoir un DNotify aussi performant.
Si DNotify n'était pas performant (pare exemple ne pouvait généré plus d'un évènement par seconde) il n'y aurait pas cet effet de bord sur nautilus.
[^] # Re: DNotify
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Donc l'avantage de FAM c'est que ça marche même sur les vieux noyaux qui n'ont pas DNotify
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: DNotify
Posté par gnujsa . Évalué à 3.
Autre chose, il faut plus de temps à Nautilus (que Rox) pour ce rendre compte qu'un nouveau fichier est apparu (surtout sur le bureau il me semble). Souvent, il faut même faire « actualiser ». Mais dans ce cas, c'est peut être pas un problème uniquement du à FAM.
[^] # Re: DNotify
Posté par cho7 (site web personnel) . Évalué à 1.
Toi tu ne serais pas un membre actif du projet ? :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.