Closed tjaskula closed 5 years ago
This allows developers to define custom interfaces that returns a Task<T>
. However there is one problem with this approach:
await
the Task
initiated in the Actor. If inside the Actor some asynchronous operations is started (like network download using TPL Async
operation) and this operation is async\awaited
inside the Actor, and if there is a continuation after the await
, the thread will be released and new message from the mailbox will be processed while the continuation is yet finished. So potentially we will have a problem of the continuation running on the actor state modified by other messages in the meantime.What would be better is, instead of async/awaiting` inside the operation in the actor:
Task<T>
and the continuation is executed synchronously. So while the async operation (like network operation) is executed in the background. The actor is not blocked to take next messages. async/awaited
inside the operation of the actor, the mailbox should be somehow suspended until the last continuation of the async operation is done.I consider that the current PR addresses the very basic usage of Task<T>
in Actors protocols but we should work to support more complete implementations as described above.
Please comment @VaughnVernon @zpbappi and others if you have some ideas.
To clarify @VaughnVernon what we have discussed, the proxy is not doing async/await
anymore but it is returning the original Task
to the client.
@tjaskula Awesome! 👍
@VaughnVernon Another idea would be to have a similar suspension capability as with SuspendExceptFor(...)
method for a protocol that contains Task<T>
operation. I'll try to spike something around that. WDYT ?
Ongoing work on #52 issue. Fixes on
ProxyGenerator
to come.