Discussion :

[Nisnor]

Bonjour à tous,

Cela fait quelques mois que je m'efforce de faire des applications multi-thread...Et depuis que j'ai commencé j'ai un problème récurrent et très embêtant.

J'ai une méthode qui ne peut être appelée qu'en asynchrone (une méthode WCF pour un client Silverlight). Or, dans mon cas, j'ai besoin de faire un appel synchrone sur ladite méthode (l'aspect "asynchrone" étant déjà géré par un système interne à l'application Silverlight)

La "bricole" qu'on trouve un peu partout sur le web consiste à utiliser un locker (ManualResetEvent, AutoResetEvent ...) qu'on signale à l'intérieur de la méthode de callback de l'appel asynchrone; un peu comme dans le code ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
9
 
ManualResetEvent locker = new ManualResetEvent(false);
AsyncCallback asc = new AsyncCallback((IAsyncResult es) =>
    {
         _channel.EndConnect(es);
         locker.Set();
     });
IAsyncResult res = _channel.BeginConnect(asc, null);
locker.WaitOne();

Seulement, dans ce cas là, non seulement le thread exécutant ce code est bloqué (logique) mais le thread servant à effectuer la méthode asynchrone le devient aussi (là, je capte plus!). Du coup, mon callback n'est jamais appelé et le thread exécutant n'est jamais déverrouillé.

Si quelqu'un a une explication...Et encore mieux, une solution, ça me sauverait grandement ^^

[Nisnor]

Pour faire plus complet, voici un code simplifié de ce qui ne marche pas :

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
ChannelFactory<Interface> _factory;
Interface_channel;
 
public MainPage()
{
    InitializeComponent();
 
    _factory = new ChannelFactory<Interface>("ServiceConfig");
    _factory.Credentials.UserName.UserName = "Test";
    _factory.Credentials.UserName.Password = "test";
 
    _channel = _factory.CreateChannel();
    ManualResetEvent mre = new ManualResetEvent(false);
    _channel.BeginConnect(new AsyncCallback(delegate(IAsyncResult res)
    {
            mre.Set();
    }), null);
    mre.WaitOne();
}

Là dedans, le thread s'arrête bien sur mre.WaitOne()....Mais le callback n'est jamais appelé. Pourquoi?

Edit : Je viens d'effectuer un autre test qui fonctionne :

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
 
ChannelFactory<Interface> _factory;
Interface _channel;
ManualResetEvent mre = new ManualResetEvent(false);
 
Thread t;
public MainPage()
{
        InitializeComponent();
 
        t = new Thread(Process);
        t.Start();
}
 
private void Process()
{
        _factory = new ChannelFactory<Interface>("ServiceConfig");
        _factory.Credentials.UserName.UserName = "Test";
        _factory.Credentials.UserName.Password = "test";
 
        _channel = _factory.CreateChannel();
        _channel.BeginConnect(Test, null);
        mre.WaitOne();
}
private void Test(IAsyncResult res)
{
        _channel.EndConnect(res);
        mre.Set();
}

A croire que lors d'appel asynchrone WCF, on ne peut pas verrouiller le thread de l'UI, sinon, ça verrouille aussi les appels WCF O_o?!

[tomlev]

Je ne sais pas si ça règlera le problème de thread WCF bloqué, mais voilà une technique un peu plus simple pour attendre la fin d'un appel asynchrone :

Code :

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

1
2
var asyncResult = _channel.BeginConnect(ar => _channel.EndConnect(ar), null);
asyncResult.AsyncWaitHandle.WaitOne();

(en fait tu n'as pas besoin de créer toi-même un WaitHandle, vu que IAsyncResult en fournit déjà un)

[The_badger_man]

Tout cela parait bien compliqué. Que veux tu faire exactement ? Empecher l'utilisateur d'intéragir avec l'application le temps que l'appel au WS se fasse ? Si oui, pourquoi ne pas simplement bloquer l'interface (avec un message d'attente, une animation, etc.) ?

[Nisnor]

@tomlev :
Entre temps, j'ai testé cette technique également...En vain malheureusement :s

@The_badger_man :
C'est ça oui. Quand mon appli silverlight se lance, je vérifie si des paramètres d'authentification sont déjà fournis. Si il n'y a rien, j'affiche une ChildWindow de login.

Derrière tout ça, on a fait un petit système dans lequel on spécifie quel bouton est le bouton d'annulation et quel bouton est celui de validation.

Le problème, c'est qu'avec ce système, lorsqu'on clique sur "Connexion" (passé en tant que bouton de validation), la fenêtre lève l'évènement Closing. Ce que j'aurais voulu, c'est effectuer la validation des identifiants à ce moment là et effectuer une annulation de la fermeture de la fenêtre en cas d'échec de l'identification.

Visiblement, il n'est pas possible de bloquer le thread l'UI en silverlight si on effectue un appel asynchrone vers le web (je crois qu'on avait déjà eu le même problème avec de la récupération d'image via HttpWebRequest qui ne peut se faire qu'en asynchrone)

En attendant une explication miracle, je vais me rabattre sur l'animation d'attente...

[The_badger_man]

Pourquoi tu ne supprime pas simplement le fait de spécifier le bouton de validation ? Tu fermeras la fenêtre toi même via le code si les identifiants sont corrects.

[Nisnor]

Parce qu'on a un système qui nous permet de traiter automatiquement des tâches récurrentes liées à la fermeture de fenêtre. Du coup, si je modifie le code de telle sorte à ce que quand on clique sur un bouton, ça ne ferme plus les fenêtres, ça le fera partout (même là où on voudrait conserver ce comportement...A la limite, j'pourrais rajouter un paramètre de configuration des classe de contrôle indique comment on gère la fermeture des fenêtres.)

J'suis resté sur l'affichage d'un contrôle prenant tout l'espace disponible et demandant de patienter

Cela dit, le problème initial n'est toujours pas éclairé...Dois-je passer le topic en résolu quand même ou pas?