Discussion :

[Gandahar]

Bonjour à tous,

est ce que quelqu'un peut m'expliquer pourquoi je ne sors jamais du while dans ce code ?

En fait le break est exécuté seulement si j'utilise la variable p_ok ... je pense qu'il s'agit d'un truc lié au compilateur , non ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
 
namespace FileWatcher
{
    class MyFileWatcher
    {
        public Boolean p_ok = false;
        FileSystemWatcher fsw = new FileSystemWatcher();
 
        public MyFileWatcher(){
 
            fsw.Path = @"C:\temp";
            fsw.Filter = "*.txt";
            fsw.IncludeSubdirectories = false;
            fsw.Changed += new FileSystemEventHandler(this.fsw_Changed);
            fsw.NotifyFilter = System.IO.NotifyFilters.LastWrite;
        }
 
        public void Run(){
            Console.Out.WriteLine("Go");
            fsw.EnableRaisingEvents = true;
            while (true)
            {
                    if (this.p_ok) {
                    Console.Out.WriteLine("break");
                    break;
                }
            }
 
        }
 
        private void fsw_Changed(object sender, FileSystemEventArgs e){
            this.p_ok = true;
            Console.Out.WriteLine(e.Name + " - " + e.ChangeType + " - ");
        }
    }
}

[kheironn]

Cette boucle while :

Code :

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

1
2
3
4
5
6
7
            while (true)
            {
                    if (this.p_ok) {
                    Console.Out.WriteLine("break");
                    break;
                }
            }

?

while true !!! tu ne sortiras jamais sauf si tu atteins un break.
C'est une grave erreur de conception et de codage !
Edit : si tu n'es pas certain d'avoir un break atteignable.

tu as un this.p_ok (un booléen donc) et rien dans la boucle ne vient le modifier !
S'il ne vaux pas true dès le début, tu ne sorts JAMAIS. Tu as une procédure assync pour la changer cette valeur ??? Parce que ton événement n'intervient pas pendant ta boucle qui "lock" le thread d’exécution -> boucle infini, rien ne se passe.

[tomlev]

while true !!! tu ne sortiras jamais sauf si tu atteins un break.
C'est une grave erreur de conception et de codage !

Non, c'est très classique; du moment qu'il y a bien des break accessibles. Parfois c'est plus simple à écrire comme ça, surtout si la condition de sortie est complexe (mais en l'occurrence ça n'apporte pas grand chose).

Par contre c'est pas terrible de boucler infiniment sans aucun temps d'attente entre 2 itérations. Il faudrait au moins ajouter un Sleep, ou mieux, utiliser un WaitHandle

tu as un this.p_ok (un booléen donc) et rien dans la boucle ne vient le modifier !

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

[Gandahar]

Par contre c'est pas terrible de boucler infiniment sans aucun temps d'attente entre 2 itérations. Il faudrait au moins ajouter un Sleep, ou mieux, utiliser un WaitHandle


Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

Ok merci pour le waithandle.

Concernant fsw_changed il est bien exécuté car sur la console je vois bien le writeline. Plus étonnant, si dans le while(true) je mets un

Code :

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

Console.Out.Writeline(this.p_ok);

alors le break; est bien déclenché. (d'où ma remarque lié au compilateur)

[Gandahar]

C'etait bien lié au compilateur...
En décochant "Optimiser le code" je n'ai plus le problème...

[kheironn]

Et tu comptes livrer du code désoptimisé ? Tu es sûr que c'est la bonne façon de procéder ? Je ne comprends pas bien le besoin qui t'amène à ce code, mais je m'interroge sur ce dernier.
J'imagine qu'il s'agit ici d'un exemple et que le traitement réel est plus complexe.

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

J'ai bien vu... Mais je me demande quand il passe dans son événement dans ce sample.

[Gandahar]

Le besoin est simple : créer un programme batch effectuant une action lors de l'arrivée d'un fichier (*.txt) dans un répertoire donné.

le programme doit être une application console.

Si tu as des suggestions, je suis à l'écoute...

[Gandahar]

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

Ben dans mon cas, c'est le même Thread et cela ne bloque pas....

Voici le corps du programme principal :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using FileWatcher;
 
namespace FileWatcher
{
    class Program
    {
 
        static void Main(string[] args)
        {
            MyFileWatcher f = new MyFileWatcher();
            f.Run();
        }
 
 
    }
}

[tomlev]

Voilà ce que je suggère :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Threading;
 
namespace FileWatcher
{
    class MyFileWatcher
    {
        private FileSystemWatcher fsw = new FileSystemWatcher();
        private ManualResetEvent _wait;
 
        public MyFileWatcher(){
            _wait = new ManualResetEvent(false);
            fsw.Path = @"C:\temp";
            fsw.Filter = "*.txt";
            fsw.IncludeSubdirectories = false;
            fsw.Changed += new FileSystemEventHandler(this.fsw_Changed);
            fsw.NotifyFilter = System.IO.NotifyFilters.LastWrite;
        }
 
        public void Run(){
            Console.Out.WriteLine("Go");
            fsw.EnableRaisingEvents = true;
            _wait.WaitOne();
            Console.Out.WriteLine("break");
        }
 
        private void fsw_Changed(object sender, FileSystemEventArgs e){
            Console.Out.WriteLine(e.Name + " - " + e.ChangeType + " - ");
            _wait.Set();
        }
    }
}

[Gandahar]

J'ai bien vu... Mais je me demande quand il passe dans son événement dans ce sample.

Et bien lorsque je crée ou modifie un fichier *.txt dans le répertoire C:\Temp

[tomlev]

Ben dans mon cas, c'est le même Thread et cela ne bloque pas....

Non, c'est pas le même thread, je viens de faire le test. Tu démarres le FileSystemWatcher sur le thread principal, mais les évènements se déclenchent sur un autre thread.

[Gandahar]

Voilà ce que je suggère :

Excellent !!! je ne connaissais pas cette class ManualResestEvent... Je vais regarder cela de plus près.

merci Bp

[tomlev]

Sinon, si tu tiens à utiliser un flag (ce qui à mon avis n'est pas la bonne approche), déclare le comme volatile, ça devrait régler le problème.

[Gandahar]

Effectivement c'est volatile qui me manquait dans mon exemple initial

Le mot clé volatile alerte le compilateur que plusieurs threads accéderont à la donnée membre _shouldStop, et par conséquent, qu'il ne doit pas émettre d'hypothèses d'optimisation à propos de l'état de ce membre. Pour plus d'informations, consultez volatile (Référence C#).

[tomlev]

Mais je maintiens que l'approche avec un ManualResetEvent est plus propre

Avec ta boucle, tu occupes à fond le processeur juste pour vérifier un flag le plus souvent possible ; d'une part ça ne sert à rien (tu n'as pas besoin de vérifier aussi souvent), et d'autre part le ManualResetEvent fait ça beaucoup plus efficacement, sans occuper le processeur avec le thread qui attend.

[kheironn]

Mais je maintiens que l'approche avec un ManualResetEvent est plus propre

Avec ta boucle, tu occupes à fond le processeur juste pour vérifier un flag le plus souvent possible ; d'une part ça ne sert à rien (tu n'as pas besoin de vérifier aussi souvent), et d'autre part le ManualResetEvent fait ça beaucoup plus efficacement, sans occuper le processeur avec le thread qui attend.

J'ai lu quelque part (mais pas retrouvé où) que faire des boucles "d'attente" était un très mauvaise pratique. Il était dit, dans ce même article, qu'il valait mieux faire des événements qui permettaient d'avancer.
Ma lecture est un peu ancienne et je ne me souviens que vaguement ce qui y était dit... dommage !

Si je retrouve cette référence, je colle le lien.