-
Notifications
You must be signed in to change notification settings - Fork 10.3k
SignalR: Using IAsyncEnumerable<T> and ChannelReader<T> with ValueTypes in native AOT #56179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Backlog, waiting for customer feedback. |
I found out that Blazor Server uses
Which means Blazor Server won't work if we keep this limitation. Given this information, we will need to support this scenario (at least for the server, but we might as well do the client as well). Right now, the only way I can see this working is by using pure reflection to read from the streaming objects. |
There is a scenario here we can't solve without a source generator. Say I have a Hub defined like the following: public class MyHub : Hub
{
public async Task EnumerableValueTypeParameter(IAsyncEnumerable<int> source)
{
await foreach (var item in source)
{
// do something with item
}
}
} The problem is that in order to invoke the For the other 3 cases, we can provide support on native AOT using reflection. The other 3 cases are:
For .NET 9 we are able to support these 3 cases. For the case on the server where a parameter of a Hub method takes an IAsyncEnumerable/ChannelReader of ValueType, we will continue throwing an exception for |
…ignalR native AOT Support streaming ValueTypes from a SignalR Hub method in both the client and the server in native AOT. In order to make this work, we need to use pure reflection to read from the streaming object. Support passing in an IAsyncEnumerable/ChannelReader of ValueType to a parameter in SignalR.Client. This works because the user code creates the concrete object, and the SignalR.Client library just needs to read from it using reflection. The only scenario that can't be supported is on the SignalR server we can't support receiving an IAsyncEnumerable/ChannelReader of ValueType. This is because there is no way for the SignalR library code to construct a concrete instance to pass into the user-defined method on native AOT. Fix dotnet#56179
…ignalR native AOT Support streaming ValueTypes from a SignalR Hub method in both the client and the server in native AOT. In order to make this work, we need to use pure reflection to read from the streaming object. Support passing in an IAsyncEnumerable/ChannelReader of ValueType to a parameter in SignalR.Client. This works because the user code creates the concrete object, and the SignalR.Client library just needs to read from it using reflection. The only scenario that can't be supported is on the SignalR server we can't support receiving an IAsyncEnumerable/ChannelReader of ValueType. This is because there is no way for the SignalR library code to construct a concrete instance to pass into the user-defined method on native AOT. Fix dotnet#56179
With #56079, native AOT support for SignalR client was added. But one scenario that isn't supported is to use "streaming" APIs (
IAsyncEnumerable<T>
andChannelReader<T>
) with ValueTypes. In order to work withIAsyncEnumerable<T>
andChannelReader<T>
we either need to "jump" to a<T>
generic method (which is what it does today, and not supported with native AOT because it can't generate the code up front) or by using reflection to invoke theMoveNextAsync()
andWaitToReadAsync()
methods.It was decided to not support this scenario until we get data that shows we need to implement this in SignalR.
Note that using ValueTypes in these scenarios isn't necessarily a performance gain because the
T
will be boxed (i.e. an allocation will occur) into theStreamItemMessage
in:aspnetcore/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs
Lines 856 to 858 in 206b0ae
cc @BrennanConroy
The text was updated successfully, but these errors were encountered: