ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject Re: Semaphore action
Date Sun, 17 Jan 2016 04:53:37 GMT
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