ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: .Net: separate methods for async operations.
Date Mon, 12 Oct 2015 16:53:03 GMT
In my view we should not pollute sync APIs with all async methods,
definitely we have to separate them
for better UX.

Currently on Java we have IgniteAsyncSupport with method withAsync() which
returns the same sync API
but that API works in broken manner. Instead it should look like the
following IMO

interface AsyncSupport<X> {
    X async();
}

Where X will be an interface with respective async API.  For example for
IngneCache we will have AsyncCache
with all the respective async variants of all methods. Like this

interface IgniteCache<K,V> extends AsyncSupport<AsyncCache<K,V>> {
    V get(K key);
}


interface AsyncCache<K,V> {
    IgniteFuture<V> get(K key);
}

>From implementation standpoint both interfaces can be implemented by the
same class but for user API
they will be conveniently separated. Implementation of every sync method is
trivial if we have
async counterpart: just call get() on received future.

>From documentation point of view we just have to write on each method that
it is a async variant of some
method on main API like following:

   /**
     * Asynchronous variant of method {@link IgniteCache#get(Object)}.
     */

This way we will not need to maintain the same docs for all sync and async
methods.

Sorry, I'm not an expert in .Net but I believe this approach will fit .Net
as well, so it can be consistent across platforms.

Sergi



2015-10-12 19:10 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> Do I understand correctly that you are suggesting adding "Async(..)"
> counterparts for all the synchronous methods?
>
> Are there any objections about this? If we do it in .NET, then we might as
> well do it in Java, because in my view the same reasoning can be made for
> Java. This will cause significant proliferation of Async methods. For
> example just on IgniteCache API, we will have to add about 40 Async()
> methods.
>
> D.
>
>
>
> On Mon, Oct 12, 2015 at 3:45 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > No. "await" is actually return from the method immediately. Let me show
> it
> > again:
> >
> > async Task<int> GetAndMultiply() {
> >     Task<int> res =  cache.GetAsync(1);
> >
> >     await res;
> >
> >     return res.Result * res.Result;
> > }
> >
> > maps to the following pseudo-code in Java:
> >
> > Future<Integer> getAndMultiply() {
> >     Future<Integer> res =  cache.getAsync(1);
> >
> >     return res.chain((f) => {
> >         return f.get() * f.get();
> >     });
> > }
> >
> >
> >
> > On Mon, Oct 12, 2015 at 1:36 PM, Yakov Zhdanov <yzhdanov@apache.org>
> > wrote:
> >
> > > Is current thread blocked until "await" instruction is completed in
> > > parallel thread?
> > >
> > > --Yakov
> > >
> > > 2015-10-12 10:41 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
> > >
> > > > Example with Get() operation:
> > > >
> > > > async Task<int> GetAndMultiply() {
> > > >     // This line is executed in current thread.
> > > >     Task<int> res = cache.GetAsync(1);
> > > >
> > > >     await res;
> > > >
> > > >     // This code is executed in another thread when res is ready.
> > > >     int mul = res.Result * res.Result;
> > > >
> > > >     return mul;
> > > > }
> > > >
> > > > On Mon, Oct 12, 2015 at 10:12 AM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org
> > > > >
> > > > wrote:
> > > >
> > > > > On Sun, Oct 11, 2015 at 3:42 AM, Vladimir Ozerov <
> > vozerov@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Guys, let's try keeping this topic focused on .Net please,
> because
> > > the
> > > > > > product is not released yet and we can create any API we like.
> > > > > >
> > > > > > Dima, answering your question about async/await - this is
> actually
> > > > native
> > > > > > continuation support in .Net. Consider the following .Net method:
> > > > > >
> > > > > > async void PutAndPrint() {
> > > > > >     await cache.PutAsync(1, 1);
> > > > > >
> > > > > >     Console.WriteLine("Put value to cache.");
> > > > > > }
> > > > > >
> > > > >
> > > > > And what if the method putAsync would return a value. How would
> this
> > > code
> > > > > change?
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message