J'avais la question exacte et je voulais comprendre la raison d'être de cette conception.
La réponse acceptée a parfaitement justifié la justification. Voici la confirmation de l'équipe qui a conçu cette fonctionnalité (c'est moi qui souligne):
Deux nouveaux types forment la base du cadre: A CancellationToken
est une structure qui représente une «demande potentielle d'annulation». Cette structure est passée dans les appels de méthode en tant que paramètre et la méthode peut l'interroger ou enregistrer un rappel à déclencher lorsque l'annulation est demandée. A CancellationTokenSource
est une classe qui fournit le mécanisme pour lancer une demande d'annulation et il a une Token
propriété pour obtenir un jeton associé. Il aurait été naturel de combiner ces deux classes en une seule, mais cette conception permet aux deux opérations clés (lancement d'une demande d'annulation vs observation et réponse à une annulation) d'être clairement séparées. En particulier, les méthodes qui ne prennent qu'un CancellationToken
peut observer une demande d'annulation mais ne peuvent pas en lancer une.
Lien: Framework d'annulation .NET 4
À mon avis, le fait que l' CancellationToken
on ne puisse qu'observer l'état et ne pas le changer est extrêmement critique. Vous pouvez distribuer le jeton comme un bonbon et ne jamais craindre que quelqu'un d'autre, autre que vous, l'annule. Il vous protège du code tiers hostile. Oui, les chances sont minces, mais j'aime personnellement cette garantie.
Je pense également que cela rend l'API plus propre et évite les erreurs accidentelles et favorise une meilleure conception des composants.
Regardons l'API publique pour ces deux classes.
Si vous deviez les combiner, lors de l'écriture de LongRunningFunction, je verrai des méthodes comme ces multiples surcharges de 'Cancel' que je ne devrais pas utiliser. Personnellement, je déteste aussi voir la méthode Dispose.
Je pense que la conception actuelle de la classe suit la philosophie du «gouffre du succès», elle guide les développeurs pour créer de meilleurs composants capables de gérer l' Task
annulation, puis les instrumenter ensemble de nombreuses manières pour créer des flux de travail compliqués.
Permettez-moi de vous poser une question, vous êtes-vous demandé à quoi sert le jeton. Cela n'avait aucun sens pour moi. Et puis j'ai lu Annulation dans Managed Threads et tout est devenu limpide.
Je crois que la conception du cadre d'annulation dans TPL est absolument de premier ordre.