Timeout Pattern - Quelle est la gravité de Thread.Abort ?

Question

J'ai lu sur différents sites web que Thread.Abort n'est pas très bon à utiliser. Dans ce cas, comment implémenter un modèle de délai d'attente ? Par exemple, j'ai lu que MS utilise le modèle ci-dessous (que j'ai enveloppé dans une méthode d'extension) dans l'ensemble du cadre. Personnellement, je pense que c'est une extension plutôt cool, mais je suis inquiet à propos de Thread.Abort. Quelqu'un a-t-il une meilleure solution ?

 public static bool CallandWait(this Action action, int timeout)
    {
        Thread subThread = null;
        Action wrappedAction = () =>
        {
            subThread = Thread.CurrentThread;
            action();
        };

        IAsyncResult result = wrappedAction.BeginInvoke(null, null);

        if (((timeout != -1) && !result.IsCompleted) && (!result.AsyncWaitHandle.WaitOne(timeout, false) || !result.IsCompleted))
        {
            if (subThread != null)
            {
                subThread.Abort();
            }

            return false;
        }
        else
        {
            wrappedAction.EndInvoke(result);
            return true;
        }
    }

Answer 1

En fait, il s'agit d'interrompre une action qui (pour autant que nous le sachions) n'a pas de moyen gracieux de s'interrompre.

Cela signifie qu'il n'y aura pas de sûr moyen de l'interrompre. Thread.Abort n'est tout simplement pas une bonne chose à faire - il y a plusieurs conditions de course et des situations horribles dans lesquelles vous pouvez vous retrouver (voir le lien dans la section Réponse de Richard ). J'essaierais désespérément d'éviter de vouloir annuler des actions qui ne connaissent pas l'annulation - et si vous devez absolument avoir pour le faire, pensez à redémarrer toute l'application ensuite, car vous pourriez ne plus être sain d'esprit.

Answer 2

Potentiellement très mauvais.

Le thread interrompu pourrait laisser l'état partagé corrompu, pourrait laisser des opérations asynchrones en cours d'exécution, ...

Voir le blog de Joe Duffy : "Code géré et durcissement des exceptions asynchrones". .

Answer 3

C'est une mauvaise chose car le fil de discussion peut se trouver dans un état incohérent ou au milieu d'un travail, et ne pas avoir l'occasion de s'éclaircir.

Pour le fermer correctement, vous lui signalez d'arrêter ce qu'il est en train de faire en appelant une méthode ou en définissant une propriété, puis vous utilisez Thread.Join pour attendre qu'il se ferme avant de fermer votre application ou de passer à d'autres tâches.