)Le principe général c'est qu'on te fourniras « jamais » de tâche non démarrée… (ou oui, on peut toujours faire de la merde, rien ne l'interdit
) C'est simple, on te retourne une tâche, et tu l'attends quand ça te chante. (ou bien tu ne l'attends pas, mais c'est pas recommandé et probablement contreproductif)La méthode Start sert si tu as besoin de bidouiller des choses avec l'objet Task avant qu'il soit démarré. (i.e. tu as besoin de séparer la construction et l'exécution, par exemple pour mettre en cache l'instance de l'objet Task), ce qui n'est pas le cas général.
La finalité est assez simple:
Tu as un point de vue « fournisseur » où tu fournis une tâche « démarrée » d'une de ces trois façons:
- Contrôlée extérieurement (TaskCompletionSource)
- Représentant l'exécution d'une méthode plus ou moins coûteuse en CPU (à priori sur un autre thread)
- Représentant la continuation d'une autre tâche (via .ContinueWith)
Tu as un point de vue « consommateur » où on te fournis une tâche qui se finira un jour: (Ou qui est déjà finie, peu importe, le comportement est identique)
- Tu peux te chaîner dessus avec .ContinueWith pour exécuter du code à la fin de la méthode.
- Tu t'en fous de l'asynchrone, mais tu as besoin de synchroniser un thread, donc tu utilises le WaitHandle pour attendre le signal de fin.
- Tu n'as pas de boucle d'évènement, donc tu utilises Wait(), pour attendre la fin.
Et le reste, et c'est très important, tu t'en fous.
Bref, si tu fournis ton API via Task, c'est une API qui suit le modèle asychrone. i.e. t'es pas obligé de bloquer (volontairement) ton thread pour attendre la fin.
(Oh et on a pas parlé du support des jetons d'annulation, mais je suppose que tu trouves ça superflu également ?
)