Alexey, .NET thick API delegates to Java directly.
When you do ICache.PutAsync(): * Future is created on Java side, .listen() is called * TaskCompletionSource is created on .NET side, its Task is returned to the user * Operation completes, Future listener is called on the Java side * Listener invokes JNI callback to .NET, where TaskCompletionSource.SetResult is called Therefore, .NET user code (in ContinueWith or after await) will be executed on the Java thread that invokes the future listener. After the proposed fix, future listeners will be invoked on ForkJoinPool#commonPool (instead of striped pool). So .NET continuations will end up in commonPool as well, which solves the problem for .NET automatically, no changes required. Does that make sense? On Tue, Mar 16, 2021 at 1:52 PM Alexey Kukushkin <kukushkinale...@gmail.com> wrote: > Hi Pavel, > > Extending Java async API with additional Executor parameters looks OK to > me. > > It is not clear from the IEP how you are going to do that for .NET async > API. My understanding is in .NET we do not add any Executors. Instead, the > Ignite Async API should use (SynchronizationContext.Current ?? > TaskScheduler.Current) by default and it should have exciting behavior (use > Ignite striped pool) if ConfigureAwait(false) was specified for the Task > result. > > Is my understanding correct? > > > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn <ptupit...@apache.org>: > > > Igniters, > > > > Please review the IEP [1] and let me know your thoughts. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor > > > > > -- > Best regards, > Alexey >
