Re: Sync vs async APIs in Ignite 3

Ivan, We are not going to adopt C++20 in the near future, as new standards are not adopted as fast in C++ world and if we'd do that most probably almost none of our users could use our client. But yeah, if we'd use coroutines, I'd probably suggest that we only provide the async API. Best Regards

Re: Sync vs async APIs in Ignite 3

Igor, and what about C++20 and coroutines [1] [1] -- https://en.cppreference.com/w/cpp/language/coroutines чт, 9 сент. 2021 г. в 14:12, Igor Sapego : > Well, fortunately we do not provide a C client if you don't consider ODBC > as one so we should not think about it. For C++ I believe we should

Re: Sync vs async APIs in Ignite 3

Well, fortunately we do not provide a C client if you don't consider ODBC as one so we should not think about it. For C++ I believe we should use standard std::future+std::promise for async, but still can provide sync methods, built on top of async methods. There is no continuation problem in C++ A

Re: Sync vs async APIs in Ignite 3

And what about C/C++? There are so many options for them... чт, 9 сент. 2021 г. в 13:00, Pavel Tupitsyn : > Talked to Ivan in private, and came up with the following per-language > summary: > > * Java: sync and async > *. NET: only async > * Python: sync and async > * JavaScript: only async (syn

Re: Sync vs async APIs in Ignite 3

Talked to Ivan in private, and came up with the following per-language summary: * Java: sync and async *. NET: only async * Python: sync and async * JavaScript: only async (sync is not possible) Thin clients in other languages are to be discussed. On Thu, Sep 9, 2021 at 11:49 AM Ivan Daschinsky

Re: Sync vs async APIs in Ignite 3

>> You can mix them easily. This is far from easily (you have already mentioned continuation problem), but for i.e. in python it is absolutely not. For kotlin it is a little bit easier, but also not fluent and a little bit ugly. чт, 9 сент. 2021 г. в 11:37, Pavel Tupitsyn : > Ivan, > > > Pavel, i

Re: Sync vs async APIs in Ignite 3

Ivan, > Pavel, is it really true, that in .NET sync versions of libraries and tools > are completely eliminated? Far from being eliminated, but there is a movement in this direction. For example, HttpClient [1] only provides async variants for most of the methods. Exposing sync wrappers for asyn

Re: Sync vs async APIs in Ignite 3

>> 2. In languages with proper async support (async-await, etc.), we can skip sync API altogether. It sounds pretty strange, as for me. Usually you cannot mix both functions easily, it is called blue-red functions problem [1] In python you definitely cannot do sync over async, for example (principa

Re: Sync vs async APIs in Ignite 3

To put it another way: - true sync operation completes by itself - sync-over-async operation requires another thread to complete On Wed, Sep 8, 2021 at 10:15 PM Pavel Tupitsyn wrote: > Val, > > That's exactly what I have in mind. > Yes, we block the user thread, but then we should unblock it by

Re: Sync vs async APIs in Ignite 3

Val, That's exactly what I have in mind. Yes, we block the user thread, but then we should unblock it by completing the future. We can't complete the future from a Netty thread [1], so we'll need some other thread from some executor. If there are no threads available (because they are blocked by t

Re: Sync vs async APIs in Ignite 3

Pavel, I might be missing something - could you please elaborate a little more? When I say "sync on top of async", I basically mean that (for example) 'insert(..)' is equivalent to 'insertAsync(..).join()'. In my understanding, it only blocks the user's thread. Am I wrong? Or you have a differen

Re: Sync vs async APIs in Ignite 3

Val, Agree with your points. > async API should be primary It should be noted that all our APIs are inherently async, because thin client is implemented asynchronously. > with the sync version build on top We should document somehow that sync APIs are based on async ones, because this may be

Re: Sync vs async APIs in Ignite 3

Hi Val, I'd highly support an async first API based on CompletionStage or its subtypes like CompletableFuture. In Ignite 2 we've written a wrapper library around IgniteFuture to provide CompletionStage instead be