Sympa le lien...

• [^]Re: Sympa le lien...

  Posté par 007 () le 25/08/2004 à 21:04. (lien). Évalué à 2.

  Un vieillard au pays des Gnome...

DNotify

• [^]Re: DNotify

  Posté par 007 () le 25/08/2004 à 21:25. (lien). É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 007 () le 25/08/2004 à 21:28. (lien). É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 Frédéric Péters (page perso, ) le 25/08/2004 à 22:30. (lien). É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/(...)

    • [^]Re: DNotify

      Posté par L (page perso, ) le 25/08/2004 à 22:38. (lien). Évalué à 2.

      > 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)
      
      En tout cas, pour ROX ce n'est pas vraiment un problème car il n'affiche que le contenu d'un seul dossier dans une fenêtre à un moment donné. Je suppose que c'est une des raisons du choix de DNotify.
      
      > grosse perte de perfs quand modifs fréquentes (ce que gamin contourne en passant au polling dans ces cas-là)
      
      Là je ne comprends plus : il me semble que DNotify (et autres technologie du genre) a justement été créé pour éviter le pooling qui est plus gourmand en ressources CPU. Aurais-je manqué ou mal compris un point particulier ?

    • [^]Re: DNotify

      Posté par 007 () le 25/08/2004 à 22:55. (lien). É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 Frédéric Péters (page perso, ) le 26/08/2004 à 16:45. (lien). É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 007 () le 26/08/2004 à 17:41. (lien). É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 Infernal Quack (Jabber id, page perso, ) le 25/08/2004 à 22:08. (lien). É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

  • [^]Re: DNotify

    Posté par L (page perso, ) le 25/08/2004 à 22:34. (lien). Évalué à 2.

    Et tout cas, DNotify est disponible au moins depuis le noyau Linux 2.4.24 car j'utilise ROX depuis ce noyau là. Après effectivement, j'ai entendu dire que les noyaux 2.4.x beaucoup plus anciens n'intégraient pas DNotify.

• [^]Re: DNotify

  Posté par gnujsa () le 25/08/2004 à 22:27. (lien). É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 cho7 (page perso, ) le 26/08/2004 à 06:55. (lien). É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 ? :)

  --
  le python, c'est bon