La façon la plus simple de faire une méthode "fire and forget" en C# ?

Question

J'ai vu dans WCF ils ont le [OperationContract(IsOneWay = true)] l'attribut. Mais WCF semble un peu lent et lourd juste pour faire créer une fonction non bloquante. Idéalement il y aurait quelque chose comme static void nonblocking MethodFoo(){} mais je ne pense pas que cela existe.

Quel est le moyen le plus rapide de créer un appel de méthode non bloquant en C# ?

Par exemple

class Foo
{
    static void Main()
    {
        FireAway(); //No callback, just go away
        Console.WriteLine("Happens immediately");
    }

    static void FireAway()
    {
        System.Threading.Thread.Sleep(5000);
        Console.WriteLine("5 seconds later");
    }
}

NB : Tous ceux qui lisent ceci devraient réfléchir pour savoir s'ils veulent réellement que la méthode se termine. (Si la méthode doit se terminer, alors dans certains endroits, comme une application ASP.NET, vous devrez faire quelque chose pour bloquer et garder le fil en vie. Dans le cas contraire, cela pourrait conduire à une situation de "feu-forget-mais-ne-jamais-exécuter-au-fait", auquel cas, bien sûr, il serait plus simple de ne pas écrire de code du tout. ( Une bonne description de la façon dont cela fonctionne en ASP.NET )

Answer 1

ThreadPool.QueueUserWorkItem(o => FireAway());

(cinq ans plus tard...)

Task.Run(() => FireAway());

comme l'a souligné luisperezphd .

Answer 2

Pour C# 4.0 et les versions plus récentes, il me semble que la meilleure réponse est maintenant donnée ici par Ade Miller : La façon la plus simple de faire une méthode "fire and forget" en c# 4.0

Task.Factory.StartNew(() => FireAway());

Ou même...

Task.Factory.StartNew(FireAway);

Ou...

new Task(FireAway).Start();

Où FireAway es

public static void FireAway()
{
    // Blah...
}

Ainsi, en vertu de l'uniformité des noms de classes et de méthodes, cette méthode bat la méthode du version threadpool de six à dix-neuf caractères, selon la version que vous celle que vous choisissez :)

ThreadPool.QueueUserWorkItem(o => FireAway());

Answer 3

À ajouter à Réponse de Will s'il s'agit d'une application console, il suffit d'ajouter une balise AutoResetEvent et un WaitHandle pour éviter qu'il ne se termine avant que le fil de travail ne soit terminé :

Using System;
Using System.Threading;

class Foo
{
    static AutoResetEvent autoEvent = new AutoResetEvent(false);

    static void Main()
    {
        ThreadPoolQueueUserWorkItem(new WaitCallback(FireAway), autoEvent);
        autoEvent.WaitOne(); // Will wait for thread to complete
    }

    static void FireAway(object stateInfo)
    {
        System.Threading.Thread.Sleep(5000);
        Console.WriteLine("5 seconds later");
        ((AutoResetEvent)stateInfo).Set();
    }
}

Answer 4

Une méthode simple consiste à créer et à démarrer un fil de discussion avec un lambda sans paramètre :

(new Thread(() => { 
    FireAway(); 
    MessageBox.Show("FireAway Finished!"); 
}) { 
    Name = "Long Running Work Thread (FireAway Call)",
    Priority = ThreadPriority.BelowNormal 
}).Start();

En utilisant cette méthode par-dessus ThreadPool.QueueUserWorkItem, vous pouvez nommer votre nouveau thread pour faciliter le débogage. N'oubliez pas non plus d'utiliser un système de gestion des erreurs complet dans votre routine, car toute exception non gérée en dehors d'un débogueur entraînera une panne brutale de votre application :

Answer 5

Appeler beginInvoke et ne pas attraper EndInvoke n'est pas une bonne approche. La réponse est simple : La raison pour laquelle vous devez appeler EndInvoke est que les résultats de l'invocation (même s'il n'y a pas de valeur de retour) doivent être mis en cache par .NET jusqu'à ce que EndInvoke soit appelé. Par exemple, si le code invoqué lève une exception, celle-ci est mise en cache dans les données d'invocation. Elle reste en mémoire jusqu'à ce que vous appeliez EndInvoke. Après avoir appelé EndInvoke, la mémoire peut être libérée. Dans ce cas particulier, il est possible que la mémoire reste jusqu'à ce que le processus s'arrête, car les données sont maintenues en interne par le code d'invocation. Je suppose que le GC pourrait éventuellement les collecter, mais je ne sais pas comment le GC saurait que vous avez abandonné les données ou que vous avez simplement pris beaucoup de temps pour les récupérer. Je doute qu'il le sache. Une fuite de mémoire peut donc se produire.

Vous trouverez plus d'informations sur http://haacked.com/archive/2009/01/09/asynchronous-fire-and-forget-with-lambdas.aspx