ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@gridgain.com>
Subject Re: .Net: separate methods for async operations.
Date Tue, 13 Oct 2015 08:54:15 GMT
> I disagree here. I think consistency matters.
> Moreover, based on the previous .NET examples you have provided, I do not
see much difference between .NET and Java, other than different syntax

What really matters is consistency with the rest of .NET platform. There
are clear design guidelines:
https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
These guidelines are followed throughout standard APIs. Everyone is used to
them.

Really, there is no need to invent anything. It won't be better. "When in
Rome, do as the Romans do".

Thanks,


On Tue, Oct 13, 2015 at 8:56 AM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Dima,
>
> I do not like JSR 107 v1.1 approach. First, it is not user friendly.
> Second, it is prone to deadlock/starvation problems we are currently
> discussing in another thread because these "Collectors" are continuations
> essentially.
>
> On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > I just took a look at JSR 107, and looks like they are taking a different
> > (in my view not as elegant) route:
> >
> >
> https://github.com/jsr107/jsr107spec/blob/async/src/main/java/javax/cache/Cache.java
> >
> > Any thoughts on this?
> >
> > D.
> >
> > On Mon, Oct 12, 2015 at 11:11 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > Well, if we asume that the most common usage will be
> > > IgniteCache.async().doSomething(), then yes - backwards transformation
> is
> > > not necessary.
> > >
> > > All in all this approach seems to be the most clean among other
> > suggested.
> > >
> > > On Mon, Oct 12, 2015 at 8:38 PM, Sergi Vladykin <
> > sergi.vladykin@gmail.com>
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > I mostly agree with your points except naming and hierarchy:
> > > >
> > > > 1. I don't like CacheAsync, it is ugly.
> > > >
> > > > 2. If IgniteCache extends AsyncCache then we can't use the same names
> > for
> > > > methods, we will be forced to use *blaAsync(...)* format
> > > > which is ugly for me as well. Also this will pollute sync API with
> > async
> > > > one, while we are trying to avoid that.
> > > >
> > > > Sergi
> > > >
> > > > 2015-10-12 20:28 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org
> >:
> > > >
> > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov <
> > > vozerov@gridgain.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > > The problem with this approach is that not all methods are async.
> > > E.g.
> > > > > > name(), lock(K), iterator(), etc.. So you should either mix
sync
> > and
> > > > > async
> > > > > > methods in AsyncCache still, or expose only async methods.
> > > > >
> > > > >
> > > > > I think AsyncCache, or rather CacheAsync, should expose only async
> > > > methods.
> > > > > Moreover, should IgniteCache simply extend CacheAsync API?
> > > > >
> > > > >
> > > > > > In the latter case we will require backwards
> > > > > > transformation: IgniteCache AsyncCache.sync().
> > > > > >
> > > > >
> > > > > Not sure this is needed.
> > > > >
> > > > >
> > > > > > Consistency between platforms should have minimal priority.
.Net
> > and
> > > > Java
> > > > > > are very different. For example we cannot even have "V Get(K)"
> > method
> > > > in
> > > > > > .Net cache. Instead we have "V TryGet(K, out bool)" because
.Net
> > > > supports
> > > > > > structs and have full generics support and naive Java approach
> > simply
> > > > > > doesn't work here. Base concepts must be the same across
> platforms,
> > > but
> > > > > > methods signatures and grouping will be different.
> > > > > >
> > > > >
> > > > > I disagree here. I think consistency matters. Moreover, based on
> the
> > > > > previous .NET examples you have provided, I do not see much
> > difference
> > > > > between .NET and Java, other than different syntax. I think the
> same
> > > > > CacheAsync design can be applied to both.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 12, 2015 at 7:53 PM, Sergi Vladykin <
> > > > > sergi.vladykin@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > 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?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

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