Hi Simon,

Sorry for the period of silence. I’m somewhat busy with a customer engagement, 
so not always able to respond as quickly as I’d like.

> On 12 Oct 2016, at 13:21, Simon Chemouil <ecli...@mithrandir.net> wrote:
> Hi!
>> What you’ve described is how you would provide your own Promises
>> implementation (see also the Aries Promise
>> implementation: 
>> https://github.com/apache/aries/tree/trunk/async/promise-api/src/main/java/org),
>> and could be what you choose to do. I would, however, consider
>> attempting to reuse the Aries implementation first (or even contributing
>> to it). 
> I had another look at the Aries implementation. It is interesting that
> you treat the chained promises differently than onResolve runnable
> callbacks (by not executing the chain is a separate executor). Do you
> expect the chain to be non-blocking, and onResolve runnable callbacks to be?

The chained functions do eventually delegate to onResolve, and should be 
running in the external executor…

Part of running in a separate thread is to avoid the problems that you see when 
people do have long-running/blocking code in callbacks. After all, we can’t 
police the code our users write :)

> I'll think about contributing a flag (or alternative implementation)
> that runs callbacks in the resolving thread. In general, I am also
> interested in minimizing the overhead associated with promises. Do you
> have any benchmarks to compare alternative implementations?

I do not have benchmarks, but would be interested in seeing them. There may 
well be places where a “SameThreadExecutor” might be helpful.

>> The Aries implementation is somewhat different from the default OSGi
>> implementation, as it also
>> provides org.apache.aries.async.promise.PromiseImpl as an exported type.
>> This gives you the ability to directly control which executor is going
>> to be used if you call new PromiseImpl(executor) instead of new
>> Deferred(). Note that you could do this inside your Execution Service
>> without requiring that anyone else use Aries Promises, it is simply an
>> implementation detail of the internals of your service.
> I can see myself replacing those calls to SomeService.deferred() that
> instantiate the right object (PromiseImpl) with the right setup
> (executor/scheduler/callback strategy). I'd rather avoid depending
> directly on Aries’ PromiseImpl in case the API evolves in another direction.

Which API is this? The Aries Promise is highly unlikely to change its 
constructors, and OSGi Promises are highly unlikely to break backward 
compatibility (it would be the first OSGi spec to do so), and I’m not expecting 
to see a Promises 1.2 any time soon (the API feels pretty complete at this 

> I am still not sure if it's worth it to pass an extra reference (and a
> service reference that might be stalled) to an object that should
> ideally be super cheap to instantiate for two methods that can be
> implemented externally, just for the sake of brevity :).

If you have ideas on how to improve the Aries implementation then contributions 
are gratefully received! :)

>> The model that OSGi tries to promote is one of maximum sharing within a
>> given set of constraints. It is therefore possible for lots of people to
>> use, and implement, promises simultaneously within the framework. The
>> important things are:
>>  * Anyone who wants to use *or* implement the API must import it
>>  * Anyone who wants to provide the API must export it
> [snip]
>> I hope that makes sense - it can be a little brain-bending when you
>> first think about it!
> Your explanation totally makes sense and confirms I understood it right :).
> Thanks again for your answers!
> Simon
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

OSGi Developer Mail List

Reply via email to