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. >
