There are plenty of blog articles on how this can get messed up.Īdditionally note that if your caller never waits on the task, any exception thrown within the task will never be raised such that you can see the error.įinally, I wouldn't bother using async/await at all here. If so then be aware that you can quite easilyĭeadlock the UI thread if you're using UI handlers to trigger this process. I also notice you're not using ConfigureAwait which tells me this could be happening on a UI thread.
#Torchat awaiting return connection code#
Looking at the code I'm really curious about the _context field and whether it is thread safe or not. If the task is never completing then the issue is with your task lambda. Never returning back to the caller then I'd say the issue is on the caller side. Until the task completes it'll never trigger the return statement. It never returns a value or this method never returns at all? Stepping through your code, when you hit the await your method should immediately return to the caller. Google for "UI thread deadlock async" to get several blog articles about this issue. thread is blocked waiting for the method to complete the continuation cannot run so we deadlock No ConfigureAwait so back on UI thread but since the UI The UI thread is blocked waiting for this to return Here's a sample of what could cause it but I haven't tested it If that thread is busy (or blocked waiting on the results) then you deadlock. Since you didn't specify ConfigureAwait(false) the continuation has to run on the UI thread. But your async method will have a continuation that has to execute It has 2 choices, it can either await on the task or continue without waiting (the common case with a void event handler). When the task completes the thread continues. Until the task completes your method is blocked as is the caller. Inside the method you call Task.Wait to wait for the results. If you aren't using async/await then when the UI thread calls your method it is going to get a result back, that is aīlocking call. My gut instinct is that you may be deadlocking the UI thread (or whatever thread you are calling this method from). It would also include anything that relies on thread-local storage. This would include anything that touches the UI elements. In general that is what you want so the general recommendation is to do that.īut there are some cases where you cannot/do not want to do that. If the continuation doesn't actually need to run onĪ particular thread (a common case) then ConfigureAwait(false) tells the runtime that the continuation can be run on an arbitrary thread. In the case of a method called from the UI that is the UI thread. By default when you await on a task and the task completes the continuation has to be run on the thread that triggered the original call.
0 kommentar(er)
