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 <andrewkor...@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 <dsetrak...@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 <andrewkor...@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. > > > > > > >
