2

How can I properly extract an HttpResponseMessage Content property (of type HttpContent) in .NET Standard 2.0 plain synchronous manner, acquired after using asynchronous await HttpClient.SendAsync(request), without using the deadlock dangerous task Result property nor Wait() method?

Background: A .NET Standard 2.0 C# library consumes some API in asynchronous manner using await HttpClient.SendAsync(), but sometimes it needs to extract and de-serialize the response content on demand in plain synchronous manner, i.e. via a property that initializes some Lazy object for it.

The API request is like this:

HttpResponseMessage response = await HttpClient.SendAsync(request).ConfigureAwait(false);

while the corresponding asynchronous Content extraction to string operation would be like this:

string content = await response.Content.ReadAsStringAsync();

Then, the lazy property (synchronous) initializer would acquire the string result like this:

string result = (await response.Content.ReadAsStringAsync()).Result;

or, sometimes better:

string result = Task.Run( () => response.Content.ReadAsStringAsync() ).Result;

Both cases, however, might cause deadlock, depending on the context.

Challenge: The suggested solution for libraries is to use plain synchronous reading in synchronous calls, i.e. using a synchronous response.Content.ReadAsString() instead of asynchronous response.Content.ReadAsStringAsync().

However, such synchronous method does not exist and is not described by the .NET Standard 2.0 HttpContent class documentation, although it does in other version(s), i.e. the .NET 6 version of the class.

Is it possible to implement it in some way in .NET Standard 2.0, i.e. using synchronous StreamReader and JsonSerializer, or any other safe way and how?

Thanks in advance.

cobrajohngs
  • 29
  • 4

1 Answers1

1

How can I properly extract an HttpResponseMessage Content property (of type HttpContent) in .NET Standard 2.0 plain synchronous manner, acquired after using asynchronous await HttpClient.SendAsync(request), without using the deadlock dangerous task Result property nor Wait() method?

You have two options:

  1. Fix the library so that it no longer requires synchronous code.
  2. Block on the task in a way that doesn't cause deadlock.

The first option fixes the requirements:

it needs to extract and de-serialize the response content on demand in plain synchronous manner, i.e. via a property that initializes some Lazy object for it.

So, if you have to asynchronously initialize a lazy object, change the lazy object so that it supports asynchronous initialization. E.g., use AsyncLazy<T> from my AsyncEx library, or use Lazy<Task<T>>.

This is the best solution.

The alternative solution is to block on the asynchronous code, using one of the hacks mentioned in my article.

The API request is like this... Then, the lazy property (synchronous) initializer would acquire the string result like this...

It's not at all clear how the code will use await for the API request and yet avoid await for reading the response content, and remain overall synchronous.

Both cases, however, might cause deadlock, depending on the context.

Not at all. The Task.Run one will not deadlock. The article you reference is rather confusing in how it uses the "deadlock" term, conflating it with thread pool exhaustion. I recommend not worrying about thread pool exhaustion in your library; if you must provide a synchronous API, then that API will block the calling thread by definition - there's no way around that, so there's no need to worry about it.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • many thanks for your response! - You say <> This is because the library aims to provide quick and asynchronous API consumption, basically multiple POST requests, without examining the response content if Response code is OK. So the response content is needed to be extracted & de-serialized only in rare failure cases in which synchronous is accepted. – cobrajohngs May 14 '22 at 23:16
  • - You say <> I trust your answer, and to be honest I cannot really tell myself if it will be deadlock or thread pool exhaustion, but I would prefer avoiding both. Sure, pool exhaustion is not the same severe as deadlock. – cobrajohngs May 14 '22 at 23:17
  • - AsyncLazy is already tried and passed the tests, but I really hate using await on properties access. I think it goes against the properties semantics and async method would be a better choice. – cobrajohngs May 14 '22 at 23:17
  • - As about blocking on the asynchronous code using one of your article hacks, which specific hack of all you would recommend as most appropriate for the case? And would it be better option than the Task.Run? – cobrajohngs May 14 '22 at 23:17
  • 1
    There's another option, then: if your API allows it, you can enforce `HttpCompletionOption.ResponseContentRead` and then all the content-reading APIs will complete synchronously. If you insist on blocking a thread, I'd recommend the thread pool hack. – Stephen Cleary May 15 '22 at 01:14
  • Enforcing `HttpCompletionOption.ResponseContentRead` is not accepted as the library needs to provide the asynchronous benefits in normal operation, with the Content deserialization to be an exceptional case (in failures only). – cobrajohngs May 15 '22 at 03:18
  • The thread pool hack looks like the same as the `Task.Run` alternative discussed earlier (above). Isn't it the same thing? – cobrajohngs May 15 '22 at 03:21
  • Btw, what I think is the best solution so far, is to get rid of the properties idea and replace it with proper `async Methods()` for de-serializing the content. `Task.Run` hack also looks good, as long as it can not cause thread deadlock. But the problem starts getting interesting and I would like to know more ideas/solutions, if any. :-) – cobrajohngs May 15 '22 at 03:25