My initial confusion was due to I did not know the TaskCompletionSource.SetResult() internally handles SynchronizationContext captured before the async operation. I thought we would have to do it in Ignite. Now I know that and have no problems with the IEP.
ср, 17 мар. 2021 г. в 11:18, Pavel Tupitsyn <ptupit...@apache.org>: > Denis, > > > we don't try to solve the problem mentioned in the IEP > > The problem: user code executes on striped pool (which causes issues) > The solution: don't execute user code on striped pool > > I believe this solves the problem and removes any and all restrictions > for async listeners/continuations. Am I missing something else? > > On Wed, Mar 17, 2021 at 10:16 AM Denis Garus <garus....@gmail.com> wrote: > > > Hello! > > > > As I understood, we don't try to solve the problem mentioned in the IEP: > > there is unexpected behavior, > > users should carefully read the docs to know about this, and so on. > > A thread that executes an incorrect listener hung in any case, > > and the suggested solution is to change the pool which owns this thread. > > Did you consider an option to execute user-defined listeners with a > > timeout? > > I think that implicit using java pools to run a code that can be hung is > a > > questionable solution. > > > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin <kukushkinale...@gmail.com > >: > > > > > Pavel, > > > > > > So what you are saying is submitting a continuation to .NET Thread Pool > > > already respects current SynchronizationContext and ConfigureAwait. In > > > this case the IEP looks complete (for some reason I thought that we > > should > > > take care about the SynchronizationContext inside the Ignite.NET > > > implementation). > > > > > > -- > > > Best regards, > > > Alexey > > > > > > -- Best regards, Alexey
