Posteriormente a observar en diversos repositorios y páginas webs al concluir nos encontramos con la resolución que te enseñamos ahora.
Solución:
No me equivocaré si creo que await liberará el hilo de llamada, pero Task.Result lo bloqueará, ¿sería correcto?
Generalmente sí. await task; “cederá” el hilo actual. task.Result bloqueará el hilo actual. await es una espera asincrónica; Result es una espera de bloqueo.
Hay otra diferencia menor: si la tarea se completa en un estado de falla (es decir, con una excepción), entonces await (volverá a) plantear esa excepción tal como está, pero Result envolverá la excepción en un AggregateException.
Como nota al margen, evite Task.Factory.StartNew. Casi nunca es el método correcto. Si necesita ejecutar un trabajo en un hilo en segundo plano, prefiera Task.Run.
Ambos Result y StartNew son apropiados si está realizando un paralelismo dinámico de tareas; de lo contrario, deben evitarse. Ninguno de los dos es apropiado si está haciendo programación asincrónica.
No me equivocaré si creo que await liberará el hilo de llamada, pero Task.Result lo bloqueará, ¿sería correcto?
Tiene razón, siempre que la tarea no se haya completado de forma sincrónica. Si lo hizo, usando Task.Result o await task se ejecutará sincrónicamente, como await Verificará primero si la tarea se ha completado. De lo contrario, si la tarea no se ha completado, bloqueará el hilo de llamada para Task.Result, durante el uso await será asincrónicamente Espere para la finalización de las tareas. Otra cosa que se diferencia es el manejo de excepciones. Mientras que el primero propagará un AggregationException (que puede contener una o más excepciones), este último lo desenvolverá y devolverá la excepción subyacente.
Como nota al margen, el uso de envoltorios asincrónicos sobre métodos de sincronización es una mala práctica y debe evitarse. Además, usando Task.Result dentro de un método asincrónico es una causa de interbloqueos y también debe evitarse.