Warning : This page has been marked as an archive because the author consider that its content is no longer relevant.

Un des problèmes récurrents lorsque l’on développe une application contenant des opérations asynchrones est de tester cet asynchronisme. On souhaite vérifier le comportement qu’aurait l’application si telle ou telle opération mettait 10 secondes ou 1 minute à s’exécuter.

Prenons un exemple simple. On a une méthode MyAsyncMethod qui notifie la fin de son exécution avec un évènement MyAsyncMethodCompleted. On souhaite simuler une latence de 5 secondes sur cette méthode.

Voici le code permettant de faire cela :

public void MyAsyncMethod()
{
    Timer timer = null;

    var context = SynchronizationContext.Current;

    TimerCallback c = state =>
    {
        if (timer != null)
            timer.Dispose();

        context.Post(o => MyAsyncMethodCompleted(this, null));
    };
    timer = new Timer(c, null, 5000, int.MaxValue);
}

L’idée est que l’on va créer un timer qui attendra le temps voulu avant d’invoquer un callback.

Ce callback se chargera de disposer le timer et d’invoquer l’évènement Completed.

Le problème du timer est qu’il va invoquer son callback dans un autre thread que celui qui a initialisé l’appel.

Afin de rebasculer sur le bon thread on a sauvegardé le contexte de synchronisation dans la variable context. Ensuite, on a envoyé l’appel à l’évènement completed au contexte de synchronisation grâce à sa méthode Post. C’est un peu l’équivalent à Dispatcher.BeginInvoke pour Silverlight ou WPF mais là ça marche pour tout les threads.

Donc pour finir, pour la méthode apellante tout est transparent et on a simulé une latence.

Simple et pratique :-)

Comments