Journal Gamin

Posté par  .
Étiquettes : aucune
0
25
août
2004
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(...)
  • # Sympa le lien...

    Posté par  . Évalué à 4.

    A une petite faute typographique près, on se retrouve avec un répertoire "gamin" sous un répertoire "vieillard"... Pas très logique ça... ;-)

    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 !
  • # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: DNotify

      Posté par  . Évalué à 4.

      > Dnotify

      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  . Évalué à 2.

        > Donc Gnome et KDE va utiliser Dnotify.

        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  (site web personnel) . Évalué à 4.

        Je vais tempérer un peu, dnotify, de loin, oui, c'est bien, performant et tout. Mais ça vient quand même avec quelques problèmes importants:

        - 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  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: DNotify

          Posté par  . Évalué à 2.

          > - impossible de surveiller une hiérarchie de répertoires

          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  (site web personnel) . Évalué à 1.

            Sur la perte de perf, elle est réelle, cf récent post de Daniel Veillard
            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  . Évalué à 1.

              Tu ne comprends pas.
              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  (site web personnel) . Évalué à 2.

      FAM utilise DNotify quand il est disponible justement.
      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

    • [^] # Re: DNotify

      Posté par  . Évalué à 3.

      DNotify à l'air de mieux fonctionner: Assez souvent, je suis obligé d'arrêter famd manuellement avant de démonter une partition car elle est utilisée par famd. Je n'ai jamais eu ce genre de problème avec Rox.

      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  (site web personnel) . Évalué à 1.

      @debut_pub: ROX, un gestionnaire de fichier rapide et léger :fin_pub@

      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.