Hi Simon,

> On 11 Oct 2016, at 10:58, Simon Chemouil <ecli...@mithrandir.net> wrote:
> Hi,
> I had a look at the recently published Compendium R7 draft.
> I noticed the Promise interface has, among other changes, two new methods:
> * public Promise<T> timeout(long milliseconds)
> * public Promise<T> delay(long milliseconds)
> (I somehow suppose these are also used by the new PushStream API)

Actually they aren’t (although the PushStream has similar timeout 
capabilities). These methods are being added because there is a need for the 
behaviour. As Promises have become more widely used a common problem has been 
“what do you do when a promise doesn’t resolve?”. This can occur if the 
provider of the promise is mis-coded, or simply if the triggering event never 
occurs. Timing out is usually the right thing to do in these situations, so 
adding a primitive for that to the Promise was made a target for Promises 1.1.

A good example is when you have a Promise representing the shutdown of an 
internal component. You call shutdown and then do some other things (or even 
return for the time being) and want to do more shutdown/cleanup when the 
Promise resolves. If the internal component hangs then you will never get a 
callback to do that further work. In this case you probably still want the 
Promise to trigger so that you can log/kill/recover in some way.

> Is there any provisional reference implementation publicly available
> anywhere?

Updating the Apache Aries Async project is on my TODO list, I should have it 
done in the next couple of weeks.

> I suppose any sane implementation of these would be non-blocking, and as
> far as I can see a good way to implement them is to use a Scheduler, but
> these methods don't take a Scheduler as a parameter, and I'm left
> wondering whether I'm missing something obvious, whether the default
> implementation is blocking, or if it's getting a scheduler from
> somewhere (or worse, constructing one or using a Timer), and if so,
> where from :)

As per the Promises specification, the method must not block. The rest is down 
to the implementation of the promise - it would be perfectly valid (although 
wasteful) to create a Timer, or a ScheduledExecutorService inside each Promise. 
My plan in Aries is to share the ScheduledExecutor where possible (i.e. in 
chained promises, or promises created by the Async Service)

> Up to Promises 1.0, promises run in whatever thread we supply: either
> the calling thread or a callback thread, and all methods are
> non-blocking. Will this change with 1.1?

Non-blocking behaviour is required by the specification, but the threading that 
you describe is the behaviour of one implementation. The Promises specification 
purposefully does not define which thread is used to run the callback. Apache 
Aries always uses a separate thread to run callbacks, even in 1.0. This 
threading model gives a much greater scope for optimisation when using the 
Async Service or Remote Services.

Whilst the thread which executes a callback is not defined, the specification 
does guarantee strict happens-before relationships between a Promise resolving 
and callback execution. This ensures threading correctness where Promises are 

I hope this helps,

Tim Ward

OSGi IoT Expert Group Chair

> Thanks for pointers,
> 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