ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladisav Jelisavcic <vladis...@gmail.com>
Subject Re: Semaphore action
Date Sun, 17 Jan 2016 09:40:53 GMT
It does sounds like a useful addition,
and I believe it could be implemented easily.
I can do it if the community agrees on changing the API of the Semaphore.

Best regards,
VJ

On Sun, Jan 17, 2016 at 5:53 AM, Andrey Kornev <andrewkornev@hotmail.com>
wrote:

> Dmitriy,I don't believe it makes sense to have the action execute
> remotely. At least I didn't think of it.In my mind, the action is always
> local (that's the reason I suggested the Java's Callable in the API and not
> serializable IgniteCallable, in the first place). What the action does is
> entirely up to the user. One could fire off a remote compute if that's what
> one wants.I hope I make myself clear.ThanksAndrey
>     _____________________________
> From: Dmitriy Setrakyan <dsetrakyan@apache.org>
> Sent: Saturday, January 16, 2016 7:54 AM
> Subject: Re: Semaphore action
> To:  <dev@ignite.apache.org>
>
>
>                    Andrey,
>
>  In general this seems like a good addition. However, I do not understand
>  how you can specify an executor, given that execution could happen
>  remotely. Can you please clarify?
>
>  D.
>
>  On Fri, Jan 15, 2016 at 1:00 PM, Andrey Kornev <andrewkornev@hotmail.com>
>  wrote:
>
>  > Hi there,
>  >
>  > The Semaphore feature was a great addition to Ignite's synchronization
>  > primitive toolkit. I'd like to propose an enhancement to make Semaphore
> API
>  > even more useful.
>  >
>  > My biggest complaint about the current API is its blocking nature. For
>  > example, the only way to acquire a permit is by using the blocking
>  > acquire() method (tryAcquire() is not very useful in the cases when you
>  > MUST acquire before you can proceed). I believe that in the 21st century
>  > blocking APIs is anachronism. :))) It's a bit embarrassing even. I'm
> sure
>  > Ignite can do better than that! :)
>  >
>  > Usually a permit acquisition is followed by an action, followed by a
>  > release of the permit. I propose a simple enhancement to the Semaphore
> API
>  > that will reduce the boilerplate and make it possible to do all of that
>  > asynchronously! The new method might look like this:
>  >
>  > <T> IgniteFuture<T> acquireAndExecute(Callable<T> action);
>  > <T> IgniteFuture<T> acquireAndExecute(Callable<T> action, Executor
>  > executor);
>  >
>  > (The name could be improved, of course...) The first method would
>  > immediately return a future to be later completed by the action's
> result.
>  > The action will be executed on a thread from the Ignite's public thread
>  > pool once a permit has been acquired. Optionally, the user could
> specify a
>  > different executor using the second signature.
>  >
>  > Would the community be interested in such enhancement?
>  >
>  > Thanks
>  > Andrey
>  >
>  > PS. A subject for a separate discussion, but I believe that in the next
>  > major release Ignite should just drop the clumsy withAsync() API and
> make
>  > all blocking calls explicitly async by returning a future. In my
> opinion it
>  > would greatly simplify the API and make it more modern. Besides, I'm
> pretty
>  > sure that internally Ignite already creates futures for pretty much
> most of
>  > the API calls, so it should not cause any performance issue.
>  >
>
>
>
>
>

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